.k5login wildcard

[Dr. Greg Wettstein]

On Oct 22, 10:24am, Sam Hartman wrote:
} Subject: Re: .k5login wildcard

> >>>>> "Tim" == Tim Alsop <Tim.Alsop at cybersafe.ltd.uk> writes:
> 
>     Tim> Michael, Would you be interested in a pam authorisation (not
>     Tim> authentication) module that allowed you to store and manage
>     Tim> this account name mapping information centrally in an ldap
>     Tim> directory (or other central repository of information) ? You
>     Tim> would not need to manage .k5login files in user home
>     Tim> directories on 2000 machines if this was available ?
> 
> a PAM account module is not the right place for this.  Consider what
> happens when I ssh into a machine using GSSAPI authentication.  I pass
> along my credentials and authenticate my principal to the server
> principal on the remote side.
> 
> PAM does not provide a standardized way to let the account modules
> know what the Kerberos authentication identity is.  Nor does it really
> seem safe to use PAM for this purpose even with some non-standard PAM
> item to convey the principal.  I really want to make sure that at
> least one account module considered the principal and validated the
> mapping.  The failure mode where say only pam_unix.so is in the
> account stack and anyone gets in as any user they wish seems very
> unappealing.

Indeed, the perils of PAM.... :-)(

That being said the attractive part of PAM is that it does provide a
somewhat 'standardized' method of attacking the authorization problem.
For some definition of standardized of course.  The biggest challenge
in this whole arena is that very little consideration has been given
to the problem of scalable or distributed authorization, especially in
the OSS arena/community.

I spent a lot of time x-country skiing with my dog thinking about the
best way to integrate authorization into applications.  The KerDAP
library provides its own API to do all of this of course.  The problem
is that KerDAP isn't a standard.  The logical thing seemed to be to
implement PAM on top of KerDAP which I have been spending a lot of
time doing.

The problem is the ugliness of PAM rears its head pretty quickly.  I
posted a fairly lengthy note to this list about a month ago talking
about some of these issues.  Our biggest problem was in identity
translation although using PAM with pre-authenticated representational
identities (aka Kerberos principals) for authorization has to be a
close second.

I didn't include all of the context from the other notes in this
thread but I wanted to respond to the 'standardized' method of passing
in a pre-authenticated representational identity.  I agree with Sam
that there is really no 'standard' way of doing this.

You have to either pass in the Kerberos principal name in the
pam_start command and have your stack(s) know what is happening or use
a pam_set_item(pamh, PAM_RUSER | PAM_USER, identifier) hack.

The main problem with PAM for authorization in this arena
(pre-authenticated identities) is that it takes a source dive for just
about everything out there.  The KRB5/GSSAPI code tends to be a long
ways away from where PAM is typically implemented.  The good thing is
that once the code gets written PAM does provide some utility in the
form of an API barrier.

I've always thought that the PAM people needed or will need to go back
and take a look at authorization issues to make the package really
useful.  Either that or thecommunity needs to take a look at providing
a 'standardized' API for asking authorization questions.  It would
seem prudent to try and build on whats already out there.  That of
course may require some consensus on de-uglification... :-)

Just a couple of comments to close on Sam's issue with respect to the
danger of PAM allowing any to get in with only a pam_unix.so account
module in place:

We think, :-), this gets handled safely by the identity model that the
IDfusion authorization system is based on.  Within the Hurderos model
Kerberos/GSSAPI authentication is simply another service conveyed to
the user, as such it has its own encapsulation object in the
directory, which contains among other things the Transient Fundamental
Identity (TFI) of the user.

In order for the account module to authorize the user the module has
to combine the user TFI with the service TFI using a Kerberos service
key to yield the identity of the service instance.  The module then
verifies that the service instance identity object is in the directory
and validates the authorization using whatever attributes are in the
latter directory object.

If the outcall for PAM authorization occurs after the principal has
been validated in the server softare the Kerberos representational
identity of the user can be considered valid.  Given secured directory
contents the valid user identity yields a service instance identity
which conveys the authorization.  Sticking something like pam_unix
underneath can then be used to verify that a physical account exists
on the machine, if that is desired.

As always though with PAM one wants to carefully evaluate the chosen
PAM stack against multiple challenges lest one be surprised.  Sam's
concerns are very valid in all this.

At the risk of boring people further I won't go into the problems
associated with trying to use PAM in an application which needs to
evaluate user attributes as part of the authorization question... :-)(

}-- End of excerpt from Sam Hartman

As always,
GW

The Hurderos Project - Open Identity and Authorization Management
		http://www.hurderos.org - Coming soon.
------------------------------------------------------------------------------
"If you get to thinkin' you're a person of some influence, try
orderin' somebody else's dog around."
                                -- Cowboy Wisdom