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

On Thu, 2011-10-20 at 11:57 +0200, [email protected] wrote:
> 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.

Yes.

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

Again, yes.

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

It is an authorization decision.  Kerberos handles authentication,
proving the identity of the user as expressed by a Kerberos principal
name[1].  The pam_krb5 module also makes an authorization decision;
namely, it determines whether that principal is permitted to access a
certain local account.  Since PAM gives it only the requested account
name and no (reasonable[2]) way to provide a principal name, what it
actually does is to infer a principal name from the account name, do
authentication, and then do the authorization check.  In the absence of
a .k5login file, the authorization check is trivial, because the only
principal names it can infer are those which are authorized anyway[3].

Note, by the way, that another option which has not been discussed here
is search_k5login, which examines the requested account's .k5login file
to obtain a list of potential principals to use in the authentication
step.  Again, if this option is used, the only principals tried are by
definition those which are authorized, so the authorization check is
trivial.



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

Correct.


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

Who said anything about skipping step 2?

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

Right.  An auth module is responsible only for the authentication and
the sort of authorization that happens in what you call step 1b.


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

Well, no.  You can still have an account module which applies additional
checks.

> Well, as the acl is in fact an intersection with passwd, KDC actually
> participates in the acl.

Sure, to the extent that you can't use pam_krb5 to log in if there isn't
a Kerberos principal with the same name as your username.


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

Yes.  If you use a distributed name service, you almost certainly also
need some more powerful access control in an account management module.
Note also that on modern, fully-integrated systems, PAM account modules
are used even by services that don't use PAM auth modules.  For example,
SSH with public key userauth.

Sadly, the reality is that there are also applications which don't call
account modules at all, or don't properly respect their outcome.  The
result of this is that modules which implement the sort of access check
you're looking for generally have to support both the auth and account
phases, so that admins can configure the module into the auth stack for
such broken applications.  This problem is not as bad as it used to be,
however.

> The passwd database is not practical as an acl.

Sure it is.  We've been using it that way, on thousands of machines, for
over twenty years.  It's not practical for _everyone_, but it's
practical for a lot of people a lot of the time.


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

Again, there are two types of authorization going on here:

The sort of authorization handled in "step 1b", which is about whether a
particular Kerberos principal (or other authenticated identity) is
authorized to act as a particular user.

And, the sort of authorization handled in "steb 2", which is about
whether a particular user is authorized to use the system in a
particular way, or to access a particular service.

Both of these are authorization.  Traditionally, when we say "Kerberos
is not an authorization service", we mean both.  More recently, there
has been some evolution toward allowing Kerberos to serve as a vehicle
primarily for the first type, in the form of alternate name forms,
PAC/PAD, and so on.

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

I don't see anything that suggests "improper use".  The module's
documentation describes how to configure this module to handle Kerberos
authentication and the "step 1b" authorization for which it is
unavoidably responsible.  It does not describe issues related to correct
configuration of other parts of the system in which pam_krb5 does not
participate (i.e. the pam account stack) and which exist _whether or
not_ pam_krb5 is used.

The job of the documentation for pam_krb5 is to document the use of
pam_krb5.  Documenting the rest of the system is clearly out of scope.



[1] For now, let's ignore the fact that in modern Kerberos, you may get
    any of a number of other pieces of information which can be used to
    identify the principal in question.  For our purposes, these are
    functionally equivalent to names, and besides, pam_krb5 doesn't use
    them anyway.

[2] It could prompt for a principal name.  But in practice, the only
    conversations that you can rely on working with every application
    are those which prompt for exactly one thing which is a password
    and those which prompt for nothing, and even the latter look a
    little awkward in some apps.  This situation is improving, but not
    so much that it's reasonable for pam_krb5 to ask "and what principal
    will you be using today?" each time it is used.

[3] Of course, it's possible you could want a different access control
    model than "local-realm principal FOO is authorized for account FOO,
    for all local accounts FOO that exist".  However, that is the access
    control model that pam_krb5 currently implements.

-- Jeff