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

On Thu, Oct 20, 2011 at 04:35:32PM -0400, Jeffrey Hutzelman wrote:
> > 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

A local account is not a _service_, it is impossible to "access it".
(The actual service in question is to do something with the given
_computer_, like starting a shell.)

Thus it is improper to talk about "authorization to use an account"
without making it clear that you apparently mean delegation

 http://en.wikipedia.org/wiki/Delegation_in_IT

and also that it is delegation on authentication level, not on access
control level.

The kerberos module treats the knowledge of a certain principal password
as a proof of representing a certain local account. According to the
definition

 "the act of confirming the truth of an attribute of a datum or entity"
 (http://en.wikipedia.org/wiki/Authentication)

this is authentication nothing else.

I guess you are mislead by the fact that possessing a local account
often is treated as a sufficient condition to grant the login service.
Note that such practice is nothing else than a trivial authorization
predicate which is always true. This does not imply that assigning an
identity (which happens before this trivial step) is an authorization
decision.

Even though our discussion may seem a pure terminology exercise,
I feel it is very important to let the future Kerberos deployers
clearly distinguish between the domains of applicability of different
notions.

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

.k5login confuses (sorry, it does) authentication and authorization as
it puts an "acccess control" list on identity delegation and then assumes
that the concerned local identity is always allowed to login. Yes it was
incepted as an authorization tool, but this does not make it a proper tool.

It does not give the host administrator reliable means to control the
access even to the local login service (it is the users who control
.k5login), in fact no means for other host-related services (which PAM
stack is designed to protect). As such .k5login should never be used by
PAM. In the discussion I assumed that .k5login is not being used.

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

That is my point - you must have an account module which applies
checks given a verified (the point of authentication) local account name.
No checks of this kind mean that you use "implicit passwd+KDC based acl"
and live either uncomfortably or dangerously, or both.

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

It is not practical. The people just have accepted the limitatitons of
such a practice and feel happy as many of them do not know any better.

For comparison:
It is possible to be happy copying files (or mailing them back and forth)
between hundreds of computers and people but it is still inferior compared
to a proper distributed file system.

I had a privilege of both working with large "traditional Unix"
installations and also compare them to more structured ones, where
authentication and authorization are distinct.

That is what convinced me about the importance of orthogonalization of
(among others) name services, authentication and authorization. Unix
has mixed them together and it worked, even sufficed for a long
time. Nevertheless this didn't scale and now it is a _lot_ easier to
understand and manage the systems when we (e.g. at Chalmers) separate
the functions consequently.

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

If the module is suggested to be used as authorization means, this is improper.

If the word "authorization" in the man page would be replaced with
"delegation" (which is the actual meaning) the confusion would disappear.
It would be actually very nice.

Russ, please consider this change. "Authorization" is apparently
heavily overloaded and it took a while for myself to figure out which
term correctly describes what pam_krb5 does. A poor novice is otherwise
guaranteed to confuse delegation between identities with authorization
to a service - which is an independent decision.

Regards,
Rune