Kerberos, identities and privilege management (was: aname_to_locaname...)

On Wed, Oct 12, 2011 at 12:51:36PM -0500, Nico Williams wrote:
> > 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).
> 
> Guess what: Solaris 11 can do that.  It reconciles everything by
> storing SIDs on disk.  (I simplify.)

This is hardly OS-specific.

A straightforward "add a line to passwd/group" at login to a workstation,
from pam_script-alike, worked fine for us on Linux.

[Kerberos is the authentication authority, the login acl is stored locally
as a plain file, authorization is explicit by listing the principals
allowed to use the computer.
The local account name being used coincides with the Kerberos principal
presented at login.
(The home directory and most of the software is on NFSv4 sec=krb5*,
the access rights are enforced by the server which of course has passwd
lines for all accounts and/or groups having file areas on it, with file
system acls set up as well)
No account name database distribution means are needed.]

> UIDs and GIDs are local identities.  Sadly they have leaked out of the

Exactly...

> problem), ...  To maintain an independent UID/GID namespace on every
> host requires remapping all the time.  It also requires some form of

It is the _file_-related services which are special - because they are
normally accessed via the kernel. That's why a mapping to the local
idenity (the numerical uid) is necessary. NFSv4 introduced id mapping
for this very purpose.

Other services do not need any such remapping, not even file services
if the access to them is implemented purely in user space (I do not
mean FUSE, the files on FUSE file systems are still accessed through
system calls).

> the "truest identity" (Solaris uses SIDs for this).  Anyways, this is

I am unsure what you mean (and what Solaris 11 does). [*]

A principal (a string and a proof that one has a strong association to
this string) is a "true identity" and is suitable to be used throughout
many services, both login, file, print and so on. What would be "more
true"?

It is also ok (and generally inevitable) to use multiple "true"
identities, even simultaneously, even by the same process - if you access
resources which are provided by multiple independent administration
domains (the Web is a good example of this).

An identity can only be assumed in a context of an administration domain
who created/allocated the identity.

(You may have an identity of a Swedish citizen in the USA, and be
able to present a proof but still it is a Swedish identity. Your name
and national social security number (e.g. a string of characters with
certain constraints) has been allocated to you by Swedish authorities. By
accident, there could be someone else in USA with the same name and
social security number (!) coming from a different country - he would
be a different identity of course :) You also could possess one more
passport, from another country with a very different name and number (some
countries laws only allow local traditional names, even for immigrants,
like Iceland did) and I it would be a different and to the same degree
true identity of yours, connected to that land as the authority.)

So I find it questionable to think of a special "true" identity.
A local host OS kernel _may_ wish to only deal with identities assured
by a certain authority but even another service on the same host (say
file access) may possibly recognize a very different authority and hence
need a different identity of yours, for various fully legitimate reasons.

I guess it is detrimental to the understanding of how Kerberos is to
be deployed when the administrator or the application developer does not
clearly distinguish between the domains of applicability of identities.

Kerberos is often seen too much like a "part of an OS/host installation"
(with all implied limitations) which it fortunately is not. It is the
various clients and services who happen to run on a host but they are not
"Kerberos", just its "users".

Each of them needs understanding and configuration separately - they
are all different, even on the same host.

[*]
<OFFTOPIC, OS criticism, sorry can not help saying>
I do not really trust Solaris developers (who possibly were the
ones who designed NFS2+3 ? :) for doing "the right thing" (tm).

I would not be surprized e.g. to find out that design sanity is being
sacrificed to become "compatible with another popular OS", which has
quite different design goals (and the corresponding limitations) compared
to Unix.
</OFFTOPIC>

Regards,
Rune