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

On Fri, Oct 14, 2011 at 09:28:55AM -0700, Russ Allbery wrote:
> I think you're not understanding what I'm getting at, but I'm not quite
> following your discussion, so it may just be that I'm not understanding
> your point.

Certainly we look from different angles which makes it harder to follow
each other's thoughts. Thanks for taking the effort and going into
the details.

> In other words, adding an alt_auth_map=%s/root to the PAM configuration is
> equivalent to giving every user a .k5login file that lists both user@REALM
> and user/root@REALM and then using search_k5login.  It allows the /root
> instance to be used to authenticate to their personal UNIX account.

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

> It does *not* allow that instance to be used to authenticate to root, and
> it doesn't allow it access to any accounts other than their own.  So I

Actually it returns nothing more than (more or less reliable, depending on
the principal being used) _authentication_ information. The authorization
is done by the pam stack. If the stack allows login for everyone
successfully authenticated, it is wrong - but not your module's fault.

Would you agree? [*]

If you really suggest using the return value of pam_krb5 as an
"authorization decision", may be we still do not understand each other. I
would like to see where there is a corresponding (and vital) acl.

>     alt_auth_map=%s/root only_alt_auth
> 
> then users have to use their root instance when authenticating to sudo
> rather than their regular instance.  In other words, it lets you apply the

That's a very good example of a proper use of "more protected" principals.
Note that the rights in sudo are not determined by the principal name,
but by a quite elaborated acl.

So "bob/root" just implies more certainty about the person being Bob,
compared to using plain "bob" principal. Do we agree on this point?

> > There is nothing which prevents different people to treat the meaning of
> > the possession of such principal in different ways (having different
> > services in mind).
> 
> I don't understand what I said that would cause this confusion.  Giving
> out a root instance to someone at Stanford does not give them access to
> anything.  It *allows* them to use ksu *if* that root instance is added to

I see, I misinterpreted your description:

>> I think Stanford is a reasonably typical site in how we use
>> such instances, and if someone has access to one of our root instances,
>> that means they can get root access to a system on which we have a
>> regular account, forward tickets, and so forth

So a possession of */root is just an _additional_ prerequisite for
doing privileged things. That's good and I am glad that I was wrong.

Anyway I do not know how to explain better what I meant about the usage
of service names pattern matches for authorization (and the danger of
conflicting use for different services, including possible future ones
and so on...).

It is nothing related to pam_krb5 of yours (given that you agree on [*]
above) nor to Stanford (fortunately).

Regards,
Rune