Re: aname_to_locaname vs gssapi svc/host.domain.org@REALM

On Wed, 2011-10-12 at 19:36 +0200, [email protected] wrote:
> On Wed, Oct 12, 2011 at 11:51:39AM -0500, Harry Coin wrote:
> > Here and now, objectively,  heimdal has a function, documented and not 
> > deprecated, that converts principal names to local names, that a 'grep 
> > -r' at the top of your favorite OS source tree shows is used by nfs at 
> > the least.
> 
> Ouch.
> 
> > So, which direction is it going to be, discussed to date we have:
> > 
> > A1) Some have called this function's existence a bug
> 
> It looks like that.
> 
> > C) Let heimdal do A.  But, offer a 'reference design' for B1 that OS 
> > implementers can use for guidance.
> 
> Ouch. The bug is "the belief that this can be done"
> ("once and for all services and setups"?).

Well, no.  The bug is using this fairly legacy code far beyond its
original intended scope, which was for inferring userids for Kerberos
authenticated access to user accounts, primarily when using access
methods that don't provide a way to indicate the desired account name
separately from the name used for authentication.  For example, login.

Note that this function is not the _authorization_ mechanism for such
access; that's what krb5_kuserok() is for.  A well-behaved application
providing Kerberos-authenticated access to user accounts will probably
need to use both.

Also note that it's not intended for random other services that provide
something other than "access to user accounts"; implementations of those
things generally shouldn't be using either function.  This includes an
NFS server where the users don't really have login accounts.


For the uses for which these functions were intended, they work fairly
well and provide a significant benefit, which is that a wide variety of
applications providing this type of access all behave the same way and
obey the same access-control rules.  This is important in part because
the access controls are configured by individual users, rather than
entirely by the system administrator.

That said, the folks at MIT apparently realized some time ago that the
default inference rules would not be appropriate for all systems, and so
provided a mechanism for the system administrator to provide a different
set of rules.  Again, this really applies only to user account access
and not to services in general.  Code to support userid inference and
access control for user account access is included in the Kerberos
libraries partly for historical reasons (several applications providing
this type of access used to be included in the distribution), and partly
because the implementation needs to be shared among multiple
applications.


Once more, it is worth stressing that this interface is _not_
necessarily used for _authorization_.  That's what krb5_kuserok()
and .k5login files are for.  However, it may be part of the default
behavior in the absence of a .k5login file for a particular user;
traditionally, the absence of a .klogin file meant that access was
permitted for a local-realm principal with the same name as the user.




> This is what whould work given "equality" mapping between principal names
> and unix account names. If as you say there is some obscure heuristics
> involved, then nothing can help to handle access rights consequently.

Except, of course, giving each user an appropriate .k5login file.
But again, that only applies to user account access, and not necessarily
to NFS.


> It is the passwd string->uid database on the NFS server which has to be
> maintained to make privilege management consistent with how unix works
> (the numeric uid being the credential used by the kernel for access
> decisions). This is relevant for NFS exporting Unix file systems, of
> course irrelevant for other services which may want to maintain their
> own databases string->privileges.

Right; a key point -- mapping to UIDs is important here only because the
NFS server, or rather the filesystems it exports, use UIDs to represent
users in their access control mechanisms.  It is, of course, perfectly
feasible to have ACLs which name principals directly, but I am not aware
of any major distributed filesystem which does this.


> > Basically, the tension comes as we'd like to avoid having ldap or 
> > similar entries for every network using process on every box with uid < 
> > 1000 as the uid/gid they are assigned varies across bsd, nix , is etc.  
> > We want local process/daemon uid:gids to stay entirely local.
> 
> You do not have to synchronize the server's idea of uids with the client
> hosts' ideas, so allocate uids freely on the server, do not use that
> database for nss on the clients. Done. That's where nfs4 finally allows
> one to do right (but not with sec=sys).

It's also worth noting that every UID used by a system daemon does not
necessarily have to have a Kerberos principal.


> The custom of synchronization of unix uids/gids over a campus existed
> only for nfs's sake. There is actually no reason to have it this way
> as soon as you throw out sec=sys.

Actually, that's only mostly true.  It turns out that things work a bit
better if the UIDs visible in the filesystem match those in the client's
database.  For example, this affects whether 'ls' returns correct
results, and whether it is reasonable for a client to respect setugid
bits on files in a remote filesystem.  Also, there are unfortunately a
number of things which incorrectly guess whether a filesystem operation
will be allowed by directly examining the mode bits and UID of a file.
Most recently, I discovered that current Ubuntu kernels contain such a
check, which prevents a user creating hardlinks to his own files if the
UIDs don't match.

-- Jeff