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

On 10/25/2011 1:05 PM, Jeffrey Hutzelman wrote:
> On Mon, 2011-10-24 at 22:00 -0500, Nico Williams wrote:
>> On Mon, Oct 24, 2011 at 9:31 PM, Harry Coin<[email protected]>  wrote:
>>>   Note user whatnot on box2 has no access to whatnot's files that were
>>> written on box3, though both are served by box1.
>> *That* is not possible today.  Well, it is, but only if you map
>> whatnot/box2 and whatnot/box3 to different usernames on the server, so
>> that ls -l on box1 will show those two files as owned by different
>> users.  It *could* be made possible without having to map those two
>> principals to different users, but I'm not sure that's worth it, and
>> anyways, it would mean that the aname2lname DBs are per-share, and
>> then you've left the realm of problems that you can solve entirely in
>> libkrb5.
> 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.
>
> 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 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.

>
>> Not acceptable.  Use a real DB, not a directory of k5login files
>> searched in dirent order.  I'm irrevocably opposed to
>> non-deterministic aname2lname behavior.
> Non-deterministic behavior is a bad idea here, yes.  But something
> deterministic would be fine.  However, I'd ditch the idea that the
> file's name is significant for anything other than search order, and
> instead let the file(s) contain (user,principal) pairs.  You still have
> to search every entry, but you gain a lot of flexibility.

There is the problem of restricting access to who is allowed to see what 
matching.   Admittedly I wrote it to solve my immediate problem, but 
even in all MIT's examples they keep the whole thing down to a handful 
of strings because those implement principal pattern matching.

Also, I argue that it is deterministic if no principal in any file 
allowed to participate in the matching itself matches any other 
principal.  In that case order is unimportant and the programs presently 
offered to folk to check integrity of krb5.conf's can check that as 
well.   It becomes an o(N) solution growing with the number of files, 
and with caching becomes insignificant.   I just don't see how any of 
the alternatives proposed here can restrict which users are entitled to 
learn what others deem wise to match outside of some huge redundant auth 
scheme.   I am not opposed to allowing the files to be named anything 
and adding syntax into each to identify the intended user.   Doing that 
drifts from the familiar .k5login format I was trying to make easy of 
course.



>>> the kuserok problem at all.   This approach solves both problems and makes
>>> it possible for users that have no 'default directory'  ( grep nonexistent
>>> /etc/passwd) to be associated with kerberos principals, and only then is it
>>> possible for them to read and write over a network.
>> I'm opposed to having kuserok ever return TRUE for users for which
>> getpwnam() does not return a struct passwd.
> Agreed.  However, I'm not entirely opposed to the idea that a
> user's .k5login file might live in a central place controlled by the
> system administrator instead of in the user's home directory.

Particularly required unless kerberos is going to be in the business of 
insisting that every user has assigned to them a 'home directory' in the 
first place -- presently a false assertion across every *nix/*bsd/*is I 
am aware of.  For details try grep nonexistent /etc/passwd

Harry


> -- Jeff
>
>