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

On Sun, Oct 30, 2011 at 12:38:54AM -0700, Russ Allbery wrote:
> > On shared file systems
> > .k5login is plainly inappropriate/broken.

> It allows the user to control for themselves the set of identities
that they consider equivalent.

I find this questionable for security. Not only does a user eventually
control whether she may use a certain computer but also she may allow
the use of an identity which the host administrator does not trust.

So you rely a lot on your users. When all users are trustable
and knowledgeable, it is fine, not otherwise.

Today only a small part of computer users in the world are
knowledgeable, in contrast to the time when Kerberos was created.

> I don't think we're actually disagreeing about their separation.  Kerberos
> the network protocol doesn't do authorization.  But many of the pieces of
> software around Kerberos do both authentication and authorization because
> there are simple authorization cases that are worthwhile to provide so
> that people don't reinvent them (with new bugs).

I agree, with every word - with the following reservations:

 - this was the case at the time when the API was conceived
 - these "simple" authorization tools have a complicated and not evident
   security semantics, dependent on many particularities of the actual
   installation, shareability of file systems, other acls present on the
   system and so on; they are "simple" only in the special cases which they
   were conceived for (e.g. all users being trusted and knowledgeable)

Since then better authorization tools came into existence, like the pam
library and its pretty straightforward "pure authorization" modules
e.g. pam_listfile, so the wheel (this time also with brakes) has been
reinvented. No offence meant.

> > "authorization solution". It allows to use an alternative principal but
> > says nothing about "the actual person being compatible with the actual
> > computer".
> 
> It's an authorization solution for those simple cases where one has not
> yet needed to scale, and it scales because it's easy to attach an

Well, you let the presence in passwd decide whether one is authorized or
not. The module's role is strictly speaking delegation aka conditional
authorization as "it is OK for xxx/suffix to login _given_that_ xxx is
allowed to login".

The last and crucial part about xxx is not decided by your module in any way.

> complexity of pam_listfile and will be perfectly happy with the basic
> authorization step that the module performs.

You _do_not_ever_limit_ in the module whether xxx is allowed to login,
given that either it or its equivalent is authenticated.
Not limiting means that you do not bother about authorization, letting
passwd or whatever decide.

You may wish to call this "authorization" but this is remarkably
misleading when you write this in the documentation.

You certainly understand the ideas but do not seem to care to express
yourself in a way corresponding to the common definitions.
This hardly helps to make Kerberos well understood (and hence more useful).

Again, I appreciate your work on Kerberos and your pam module.

> That's not ideal, and indeed the way that ls and UNIX ownership works is
> quite primitive and ideally should separate the file system ownership from

Actually the whole concept of an "owner" is a trick for the sake of Unix
poor-man-acls aka mode bits. It has a sense only because it has certain
rights in certain situations. So there is no "file system ownership"
in a general case. A good file system does not need it. Real acls
are a lot better than the "tree-predefined-entries' acl" mode bits.

> the local UID to username mapping by storing an actual identity string as
> the owner.

One may wish to store some metainformation about a file, like "the
author of the last modification" but it would be hardly appropriate to
call this an "owner".

> > Or somebody is on a long leave/whatever and is not supposed to be able
> > to mess with the computer under that time, then shall we edit passwd
> > back and forth?
> 
> Sure.  Although I can't recall that case ever occuring.  Usually if an
> account needs to be frozen, they want to freeze their access to everything
> and we just turn off the Kerberos principal.

In reality we have to selectively disable services sometimes. Say, mail
reading may be allowed even if one is suspended from using the computers
at work / at school.

> there's built-in support, instead of having to distribute a text file and
> possibly merge together data with templates).  And if you're using LDAP,
> it's much easier to change user to machine mappings that way than it is to
> distribute an explicit ACL file.

The acl can be in LDAP, I just want it to be orthogonal to other
information related to the user and to the host in question.  The more
orthogonal, the more explicit - the easier to manage.

> You have to use other mechanisms, such as locking the account in
> /etc/shadow, using an invalid shell, or the like.

This is exactly the kind of unreliable and inconsistent uses of passwd
which I would hardly ever recommend to deploy. Sigh.

Regards,
Rune