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

12 okt 2011 kl. 15:05 skrev <[email protected]>
:

> Hello Love,
> 
> On Wed, Oct 12, 2011 at 10:00:27AM +0000, Love Hörnquist Åstrand wrote:
>> Mapping user/root -> root is a convention used at KTH and round in
>> stockholm, it have zero impact on security unless you also put that
>> principal into roots .k5login file. It also matches behaivor of (k)su.
> 
> A mapping is ok if made within/by a service.
> 
> Such a mapping outside a context of a certain service is meaningless.
> 
> I was talking about NFS (and privileges to read and write files on
> a server), while you seem to imply login (and the privilege to start
> processes as a certain uid on a certain host).
> 
> If an NFS server maps "user/root" to "root" and then presumably to uid
> 0, this may have far reaching consequences if this is hardwired in the
> server code, depending on the actual setup of the NFS server and on the
> principal management policies at the corresponding KDC.

Yes, using unix style authentication is bad in NFS, however, in kerberos, if you don't want a foo/root to be mapped to root, don't add foo/root to the ACL.

> It will have zero impact _if_ such principals are only being created
> for persons allowed to access the exported resources as the server's
> superuser.

I don't understand this statement wrt to krb5_aname_to_locaname and root.

> Any other use of such principal name is thus effectively
> disallowed (for a safe and reliable setup).

Its denied by default disallowed by krb5_aname_to_locaname()

> IOW use of a certain form of a principal name by a certain service
> reserves this class of names for the service. That's why I am convinced
> that conscious allocation and management of principal name space is
> crucial.

I totally disagree. This is how we get into the problem what users can't get keytab's because that will make everything insecure.

> To make it easier, it might be better to avoid hardwiring any
> meaning into the names.

It will be made easier when services adopt ACL management system.


> An explicit mapping done inside a service
> (say "abc"->"uid 0", "xyz"->"uid 0")
> does not preclude using the same names safely by another service
> (say, "abc"->"readonly", "xyz"->"superpowers").
> 
> An implicit mapping can not be used safely by unrelated services
> (login: "bob/root" -> "local administrator" on a certain workstation)
> (nfs: "bob/root" -> access to files as superuser on a server)
> "root" means very different things above even if both are referring
> to a certain Unix-privilege-allocation-(mis)feature.
> 
> Hope you see why I say that hardwiring interpretation in the code has
> security consequences.
> It is both
> 1. an allocation of a part of principal namespace for a certain service (!)
> and also
> 2. an implementation of a certain policy which _must_ be reflected by
>   management rules for such principals.

I don't understand, krb5_aname_to_locaname() consults local database to check if access is allowed, what point are you trying to make ?

> As far as I can see, the majority of people deploying Kerberos
> are hardly aware of such considerations and just expect that
> Kerberos (with its API, HowTos and tutorials) is a guide for sane
> deployment "by example". Alas, it is not. Worse, it suggests ad-hoc
> practices (as a heritage from its early development epoch?).
> Sigh.

Its well spread enough that Russ implemented something like it for his pam_krb5

	http://www.eyrie.org/~eagle/software/pam-krb5/pam-krb5.html

And if you care for documentation

	man /usr/heimdal/share/man/man3/krb5_aname_to_localname.3 



Love