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

[Andrew Deason]

On Tue, 18 Mar 2014 17:40:55 +0100
Gergely Risko <gergely@risko.hu> wrote:

> > That is specific level of "access" that I don't think exists anywhere
> > else in AFS; it doesn't have an equivalent in current normal operation
> > and may be confusing. The meaning of such an access check could also
> > change for non-rxkad security classes.
> 
> Hmm, okay, yes, and it seems very week, so I certainly don't want that.

Well maybe, maybe not (I haven't really thought about this much; I'm
just providing some info). If you're just trying to prevent "anyone in
the world" from executing the relevant RPCs, this does give you the
tools to prevent that. At least what you get with that is an identity
that is executing those RPCs that you can look at if you discover you're
getting hammered or it looks like they're scraping data or whatever.

With an anonymous connection, all you have is an IP, which is not great.
Requiring an rxkad-authenticated connection would give you a krb5
principal name (possibly restricted to specific realms), which is
better. This becomes useless if you can create a kind of anonymous krb5
identity (I think this is possible in some setups? or it's being
discussed?), but the krb5 administrator should be able to control that.

That's why I would say such an approach "gives you the tools" to prevent
anyone in the world from running these RPCs; it doesn't do it on its
own. You can look at it like it's deferring the question of
authorization to the krb5 setup. That's not "proper" since it's
effectively making an authorization decision for an AFS subsystem, but
that doesn't necessarily mean it's infeasible.

> Should we do that?  And warn administrators in the manpage that this
> restricted access is not compatible with foreign users?  Better options?

I don't think refusing foreign users would kill this; iirc they have
some other restrictions like you can't identify them as an SUser or
stuff like that. But basing this off of krb5-specific information
doesn't seem desirable; it may need to be reworked entirely for rxgk or
any other security class.

I'm not sure if we can avoid doing ptserver lookups in the vlserver
forever... it seems like that would be required for having in-band
delegated volume administration and things like that (unless we create
our own separate authz database for such operations). But I'm just
thinking aloud.

-- 
Andrew Deason
adeason@sinenomine.net