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

On Tue, Oct 25, 2011 at 1:35 PM, Harry Coin <[email protected]> wrote:
> On 10/25/2011 1:05 PM, Jeffrey Hutzelman wrote:
>> No, there's another way.  If whatnot@box2's files are all in a directory
>> tree that is _not exported to box3_ and vice versa, then indeed neither
>> user can access the other's files, even though they have the same UID on
>> the server, and the user whatnot on the server can access both sets of
>> files, provided all three have the same (server-side) UID.
>
> Right.  This is the present case pre kerberos.   Somehow there is this
> notion that a principal is entitled to access files everywhere in the realm,
> when previously under nfs4 there can be a restriction about that.

You're confused.  A principal name is only an authentication identity.
 It is NOT intended to imply authorization rights.  Each application
is supposed to implement authorization however is best for it.

For login apps, the best approach is to use krb5_kuserok() or
application equivalent.  Here krb5_kuserok() is a utility function
provided because so many apps will want to share the same facility.

For login apps, when the username is not provided, the library also
provides krb5_aname_to_localname() to derive/lookup a username
from/for a principal because again, that is a useful utility function
given how many apps will want the same facility.

For file server type applications the situation is a bit more murky.
Whereas login apps can just getpwnam(), setgid(), initgroups(), then
setuid(), file server applications -particularly kernel-mode file
servers- need the raw UID and GID values.  The reason is that
kernel-mode apps can't setuid() -- they must instead construct a
cred_t from raw inputs.

The same applies for, say, Windows, only substitute SIDs for UIDs and
GIDs.  The same goes for Solaris 11 (which supports SIDs), only add
SIDs to UIDs and GIDs.

But that's only one part of the story.  The other part is that whereas
login apps have a single user namespace, file server admins tend to
want many user namespaces.  You are a case in point.

Now, traditionally multiple namespaces meant multiple servers.  But
NFS servers provided share-level ACLs that one could use to maintain a
fiction of multiple namespaces on one server, and this has you
confused.

The way NFS (v3, v4) and RPCSEC_GSSv1 (and v2) work, you cannot
reliably determine the client *hostname* from the GSS principal name.
The reason is that most client user principal names have no hostname
in them: joe.sixpack@SOME-REALM, and RPCSEC_GSS does nothing to
authenticate a *client* and a *user* together.

This means that share-level ACLs for NFS still have to use IP
addresses and DNS.  This is insecure.  Kerberized NFS does NOT solve
this YET.

There is a new RPCSEC_GSS (v3) in progress that does address this and
therefore will allow for NFS server implementations that provide
share-level ACLs based on client credentials.  Given this, it'd be
possible to implement per-share user/group namespaces.

I hope you see now that the solutions to the problems you are upset by
belong in the NFS *server* implementation, NOT in the Kerberos
implementation.

The best that the Kerberos implementation can do for the server is
provide utilities that help the server.

I do NOT think that the Kerberos implementation should have much to do
with implementing distinct per-share user/group namespaces on the
server though.

>> Of course, this has _nothing to do with Kerberos_.  It's just applying
>> IP-address-based access control, with all of the weaknesses that's
>> always had.  If the owner of box2 uses whatnot/box2's tickets but spoofs
>> box3's IP address, he will be able to access whatnot/box3's files.
>
> Under NFS4 as well?  Note the principal names (the one's I've been villified

Yes.

> for here) in my world identify the box and the user, and n4 doesn't put
> uid:gid on the wire.  In any event firewall alarms should trigger if that
> happened as well.

See above.

Nico
--