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

[email protected] writes:

> That's bad - both that "nothing else does" which is a deliberate and bad
> choice of the setup designers, and also ".k5login" which is in the hands
> of the user instead of the host administrator.  On shared file systems
> .k5login is plainly inappropriate/broken.

I would disagree with this too.  When you're doing user management on your
systems, so that the account doesn't exist if the user doesn't have access
to it, then .k5login in a shared network file system is excellent.  It
allows the user to control for themselves the set of identities that they
consider equivalent.

It's abusable, of course, and there are times when you want to disable
that support for one reason or another (because you don't trust users to
set authorization rules for their accounts, for instance), but we've been
using .k5login in shared file systems for many years and are largely happy
with it.  It is something that you have to think about and understand the
implications of, of course.

> Hope you see that at some point it becomes crucial to separate
> authentication (which Kerberos is good for) and authorization.

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 do agree that, for sophisticated and complex situations, there should be
some way to turn off or supplement those authorization checks with more
complex ones, as there is in pam-krb5.

> Using this as the final authorization decision is possible and alas even
> default in some OS distributions and versions. This does'not make it
> reliable nor scalable.

> On the other side, as soon as the output of pam_krb5 is AND-ed with an
> explicit acl, the setup becomes general and manageable.

> So, again - no trouble with pam_krb5. It's very good and alt_auth_map
> is a very desirable and important feature.

> Regrettably, I can not agree that this feature should be treated like an
> "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
additional authorization check with an explicit ACL.  To me, that seems
like a feature, not a bug.  :)

> Please, please, add a line in the man page saying
> "Kerberos is an _authentication_ service, you should not use the return
> value of this module as an _authorization_ decision without applying
> further explicit access rules, e.g. by means of pam_listfile".

Well, I'm certainly not going to say exactly that because I think that's
bad advice for most people.  Most users of the module don't need the
complexity of pam_listfile and will be perfectly happy with the basic
authorization step that the module performs.

Security is a tradeoff against usability.  Emphasizing maximally-secure,
fully-specified role-based operation-specific ACLs, which is the logical
end point of your argument, can end up just causing people to abandon
security altogether, or weaken it to the equivalent of abandoning it,
because maintaining such a system is too much work for little gain.  One
wants to pick a security regime appropriate for the situation so that it
will actually be used and maintained.

> A teacher may wish to look at shared files created by students and refer
> to their account names or see the ownership (say with NFSv4) then their
> accounts must be present in passwd... but not the student's processes on
> the teacher's workstation! :)

This sounds like something that one would want to care about frequently,
but our experience with AFS is that having the UID to username mapping is
mostly cosmetic and for the most part people don't much care.  When they
do, they check on a shared system.

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
the local UID to username mapping by storing an actual identity string as
the owner.  But this is a standard annoyance with network file systems,
and I think people who have made extensive use of them have mostly gotten
used to it.

You can, of course, add the UID to username mapping without enabling
logins in various ways, and we sometimes do that instead.

> 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.

> What about allowing/disallowing on many computers at once? An explicit
> acl is much more easily distributable than passwd.

Actually, if you're using something like Puppet, they're of equivalent
difficulty, or actually changing /etc/passwd is somewhat easier (since
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.

> And also if you'd wish ditribute passwd for other reasons, you can't,
> if you happen to need different access lists on different computers.

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

-- 
Russ Allbery ([email protected])             <http://www.eyrie.org/~eagle/>