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

Hello Jeffrey,

On Wed, Oct 19, 2011 at 06:12:48PM -0400, Jeffrey Hutzelman wrote:
> > I feel [...] that mixing authentication and authorization
> > makes it hard to understand and manage.

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

I do not really see what you mean by "to access the indicated account".
What is "accessing" in this context?

Let us be specific, PAM works as follows:

An entity (like a human user) aks for a permission to assume a certain
local identity (supplied as an account name) for a certain purpose
(like starting a shell).

PAM stack takes the local identity name as the input and with
help of the modules evaluates whether the entity
1. has a suitable proof that the entity has a fundamental association
   to the given local identity
2. the given local identity is allowed to use the desired privilege
   or service.

Russ's pam_krb5 works like
1a. check the proof that the entity (the human) has a fundamental
    association to a _Kerberos_ identity of a certain class chosen
    by the module
    (e.g. "either the same string as the local account name
    or the same string with "/root" suffix appended)
1b. take this as a proof that the entity (the human) has also
    a fundamental association to the given _local_ identity

[This is internals of a certain module's design, which the rest of
PAM stack is unaware of]

I guess you name (1b) above "an authorization decision" while it is part
of (1) which _is_ authentication: a proof that a person "is" the _local_
account which she explicitely pretends to be.

Kerberos can not be used for step (2) as Kerberos has nothing to
do with how a certain host is set up. Its database does not contain
acls-per-host-and-service.

Simply skipping step 2 is also wrong as the resulting implicit "authorization
acl" becomes an intersection of the set of the locally known Unix
account names and of the principal names in the KDC, neither of which
generally reflect which users shall be able the use the actual computer.

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

I would say "permitted to use the service in question" where the service
can be, say, local-login, sudo, remote-login-via-ssh, younameit...

Then I fully agree that the "account" modules is for authorization,
implementing the step (2) above.

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

Yes, in such a setup it is solely the set of known account names
which is the effective login acl.

> > 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
[*]

Well, as the acl is in fact an intersection with passwd, KDC actually
participates in the acl. In special cases passwd may contain a strict
subset of the names present in KDC but this is not guaranteed by any
means.

If local accounts are created sparingly, then the local passwd mostly
is the acl. As soon as you use a distributed name service for passwd,
it becomes about as loose as KDC or much more, depending on the kind
of the setup.

> > "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_,
 ...
> and the only
> additional access control needed is to only create accounts for those
> users who are authorized to use a machine.

The passwd database is not practical as an acl.
What about selective/temporary access ban on a set of hosts?
What about installations with distributed name services, using NIS,
LDAP or whatever?

Finally, assuming that it is the passwd database that decides over
authorization, it is plainly incorrect to suggest otherwise in the
pam_krb5 man page (among others saying that identities mapping is related
to authorization, not at all: the string being checked for the presence
in passwd - the local account name - is supplied by the user and not
influenced by pam_krb5).

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

Exactly. Authorization has nothing to do with Kerberos. That's why I
argue against the module's currently suggested improper use.

Regards,
Rune