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

[email protected] writes:
> On Fri, Oct 14, 2011 at 09:28:55AM -0700, Russ Allbery wrote:

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

I'm not sure I understand what you mean by the "*" wildcards here.  Just
making sure you're not under the impression that *any* root instance can
access any account, since that's not how it works.

PAM modules do a form of authorization, although the separation in the
stack makes these things somewhat ambiguous and strange.  But they
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).

I would argue that alt_auth_map is inherently an authorization service,
not an authentication service; the authentication just reports that the
user authenticated as, for instance, rra/root.  What alt_auth_map is there
to do is to say that the user is therefore allowed to access the account
rra.  That is an authorization decision, if a somewhat primitive one.

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

No, not really, per above.

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

That's what alt_auth_map is, though.  It's an expression of an ACL.

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.

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 "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
properties as well, but they mostly amount to indirect ways of assuring
that.

-- 
Russ Allbery ([email protected])             <http://www.eyrie.org/~eagle/>