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

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.

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. Any other use of such principal name is thus effectively
disallowed (for a safe and reliable setup).

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. To make it easier, it might be better to avoid hardwiring any
meaning into the names.

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.

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.

Regards,
Rune