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

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

> making sure you're not under the impression that *any* root instance can
> access any account, since that's not how it works.

Of course. I think I do not have any problem interpreting both the
documentation and your explanations, which correspond to each other.

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 is the actual setup of a pam stack for a certain application on a
certain host which _authorizes_ as a result of evaluation of the included
modules (and of their relations described in some ugly language :)

Normally the firt step is authenticating the entity who asks for the
right or service. The authentication step may be skipped though, say if
everyone is allowed to get a cup of coffee, but only during certain hours,
then a single pam module in the stack would simply check the clock.

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

This is a kind of "anyone" authorization decision (if we look at
authentication as a separate step, which in my eyes is vital for
understanding of the results of one's design choices).

> essentially have to do authorization for shell logins, since nothing else
> does.  And Kerberos PAM modules historically do authorization via .k5login
> or similar rules (for which alt_auth_map is a replacement).

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.

A wildcard-style authorization is only appropriate in very small or very
homogenous installations, then the KDC database is used as "the acl".
On complex installations KDC may contain orders of magnitude more
principals than are authorized for any single service using authentication
against the realm.

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

> I would argue that alt_auth_map is inherently an authorization service,
> not an authentication service; the authentication just reports that the

Then its "acl"-corresponding predicate is nothing more than a (in the
best case partial) wildcard match. It is "anyone"-kind of authorization,
among authenticated entities.

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

> rra.  That is an authorization decision, if a somewhat primitive one.

Well, I guess it is where we find a common ground.

It becomes an authorization decision if used as such by the pam stack
(and can be used as such by the pam stack, in a certain setup)
but it is a very primitive decision and such setup can not scale.

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

(for the moment you suggest the opposite)

Sigh. :)

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

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

> > So "bob/root" just implies more certainty about the person being Bob,
> > compared to using plain "bob" principal. Do we agree on this point?
> 
> Yup, that's basically the goal of it.  There are a few ancillary

Nice! I think we understand each other now.

Thanks,
Rune