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

On Sat, 2011-10-15 at 23:55 +0200, [email protected] wrote:
> Hi Russ,
> 
> On Fri, Oct 14, 2011 at 09:31:58PM -0700, Russ Allbery wrote:
> > > Allowing the use of a more protected principal (or enforcing that) is
> > > good. Making authorization decisions based on the possesion of an
> > > identity falling into a "pattern" class is potentially dangerous. In the
> > > example above - if treated as an authorization decision (?) - you
> > > actually allow both "*" and "*/root".
> > 
> > I'm not sure I understand what you mean by the "*" wildcards here.  Just
> 
> I mean that if it is pam_krb5 which is "sufficient" in the pam stack
> then any person possessing the (password to the) identity XXX
> is allowed to start processes with uid=passwd_lookup(XXX).

Yes, that's correct.  That's generally how logins to UNIX systems work.

> Not the actual behaviour but the intended use of pam_krb5 is where we
> seem to disagree and were misunderstanding each other.

> > PAM modules do a form of authorization, although the separation in the
> > stack makes these things somewhat ambiguous and strange.  But they
> 
> I feel to the contrary that mixing authentication and authorization
> makes it hard to understand and manage.

It may.  Nonetheless, that's how it is, as an artifact of the way PAM
was designed back in the 1990's and, to a lesser extent, of how PAM
libraries, modules, and applications have been written since then.  A
PAM "auth" module necessarily must not only handle authentication but
also make a certain class of authorization decision; specifically, it
must decide whether the authenticated identity is permitted to access
the indicated account.  The purpose of a PAM "account" module is to make
a different class of authorization decision; namely, to decide whether
the account in question is permitted to use the system at all.

> Using the "alt"- principal mapping in pam_krb5 is useful for other
> reasons but it does not change the fact of "everyone authenticated to
> something which maps to a local account name is authorized".

Ah, but that's not necessarily true.

The authorization rule that pam_krb5 applies by default is that
principal FOO (in the local realm) is authorized to access account FOO.
This is analogous to the behavior of pam_unix, which applies the rule
that anyone who knows the "local" password for account FOO (which, BTW,
might actually come from NIS or LDAP or...) is authorized to access
account FOO.

This is what pam_krb5 is _for_ -- to allow users who have accounts on a
system to authenticate using the password of the corresponding Kerberos
principal.  Of course, it is possible to have a module which implements
a more complex rule, in which the user separately specifies the account
and principal names and an authorization check is done using .k5login.
However, that's not what pam_krb5 is for.

The question of whether FOO is authorized to use the system is another
matter entirely, and is controlled primarily by PAM "account"
modules(*).


> A wildcard-style authorization is only appropriate in very small or very
> homogenous installations, then the KDC database is used as "the acl".

Again, you appear confused.  Nothing uses the KDC as "the acl" to
control who can log in.  Only users with accounts on a system can log
in.  It's true that pam_krb5 makes the assumption that Kerberos
principals and local accounts which have the same name correspond to
each other.  But, again, that's its job.  If you have a system whose
accounts do not correspond to local-realm Kerberos principals with the
same name, then don't install pam_krb5.  Or else configure your PAM
stack so that pam_krb5 gets used only for accounts where that
correspondence exists.  Or use a more complex module which provides for
a mapping mechanism, and configure that.


> On complex installations KDC may contain orders of magnitude more
> principals than are authorized for any single service using authentication
> against the realm.

Yes, that's true.  But, as has been pointed out several times now,
nothing in pam_krb5 makes it so that all of those principals can log in
to any machine on which it is installed.

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

Such a statement is far too strong.  In the vast majority of situations
I have seen, _even in a large and diverse computing environment_,
machines using pam_krb5 or a similar mechanism to enable Kerberos
authentication to local accounts generally _do_ have an equivalence
between local accounts and local-realm Kerberos principals, and the only
additional access control needed is to only create accounts for those
users who are authorized to use a machine.

The real problem enters when you start configuring machines to treat
every user appearing in some central _directory_ service as having a
"local account".

> > To put it another way, adding alt_auth_map=%s/root to the PAM
> > configuration of a service is equivalent to adding an ACL for that service
> > saying that, for any account foo, the principals foo and foo/root in the
> > local realm are permitted to access that account.
> 
> Exactly, an _extremely_ permissive ACL. Too permissive as soon as there
> exist more principals of those forms than desirable users on this computer.

No, only slightly more permissive than the default, which is that only
the principal foo in the local realm is permitted to access that
account.

> > If your point is that one should always have explicit authorization lists
> > for each account separately and never use matching rules, I guess I
> > understand what you're saying, but I think matching rules do work in a lot
> > of situations, such as ours.  We don't create the UNIX account on the
> > system at all if that person is not supposed to have access to it.
> 
> So you are actually (ab)using the passwd database as the login acl.
> 
> Such use of it does not really fit the bill in the long run, I guess.
> 
> 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! :)
> 
> 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?
> 
> What about allowing/disallowing on many computers at once? An explicit
> acl is much more easily distributable than passwd.
> 
> 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.

All of those problems are good reasons to introduce additional
authorization mechanisms.  However, none of them have anything to do
with pam_krb5.



(*) Unfortunately, one of the realities is that not all PAM applications
correctly call the account management stack, so sometimes, depending on
the application, one has to arrange to make these sorts of decisions in
the authentication stack.  Such is life.

-- Jeff