[OpenAFS-devel] Re: Initial implementation of RestrictedQuery, please comment

[Andrew Deason]

On Tue, 18 Mar 2014 18:25:07 +0100
Gergely Risko <gergely@risko.hu> wrote:

> Oh, no, I see what you mean.  My own fake kerberos realm won't be good
> enough, because it doesn't have the cross realm ticket granting tickets
> with the target realm, right?

Yes, it won't be able to acquire a service ticket for the 'local'
afs/cell.example.com principal. It could have its own
afs/othercell.example.com principal to create its own tokens, but the
key for that service principal will not be recognized by the server,
since the key is not in the local KeyFile/rxkad.keytab.

> We're talking about users who has a valid kerberos ticket with our
> home realm or with another realm that we have cross kerberos
> relationships with, but who has no entry in ptdb or the entry can't be
> created because there is no automatic afs foreign access for that
> realm.

Yes, but it may be important to be aware that a principal doesn't always
correspond to a 'user'. As jhutz and I mentioned, there is a certain
form of principal that is effectively anonymous, but more generally a
principal can represent anything. For example, a site could maybe have a
kerberized service that lets anyone in the world do something on some
server, and they are represented by the krb5 principal e.g.
'notarealuser', and that principal is never allowed to access anything
beyond some specific basic services. And maybe the krb5 realm is huge
and handled by another team, so the AFS administrators have no idea that
that principal exists.

That may seem a little far-fetched, but the point is that simply relying
on a principal to just _exist_ is not intended to be a secure mechanism
to verify anything about the principal. So it seems a little fragile
(and confusing). That doesn't necessarily mean it's the "wrong" way to
do it, because from what I've been skimming the security here is not
protecting a super-critical resource. If it breaks, it's not like the
attacker has taken over an account or something; you're just back to the
same level of access that always existed in AFS before this was
introduced without any authz at all.

So, maybe that's okay but it's something to make very very clear in the
documentation, and is not something that should be relied upon for e.g.
compliance with government regulation, or strict site security policies,
etc etc. It's just something to make the attack surface smaller. (In
this way, it kind of reminds me of krb5 preauth.)

-- 
Andrew Deason
adeason@sinenomine.net