Re: NSS and PAM

"Jacques A. Vidrine" wrote:
> On Mon, Dec 01, 2003 at 05:48:22PM +0100, Dag-Erling Smørgrav wrote:
> > They are different issues, but in this context you can't discuss one
> > without the other.  Authentication doesn't work unless you have a user
> > to authenticate.  It makes no sense to separate them; you just end up
> > duplicating a lot of concepts and code.
> 
> Hmm, I disagree completely.  :-)  They can be separated and should be
> separated.  Systems that mix them up are flawed.  The confusion of the
> two are what *causes* the problem you bring up below (passwd(1)).

Authentication and authorization are two axis, but there's a third
axis orthogonal to those, usd for non-repudiation (identification).

The main issue that most people have missed so far in this whole
discussion is that there are three perpendicular axis, not simply
a single axis (or simply two of them, for people lik you, who've
understood the difference between the first two, but missed the
third).

[ ... ]

> It seems to me that this is a direct result of passwd(1) confusing
> authentication and authorization.  Other than determining the default
> target user name from the current UID, passwd(1) needs only to invoke
> PAM interfaces to change your password for any authentication method
> that supports password changing.

The nature of passwd is that it requires authentication in order to
grant authorization; it also has the effect of logging changes made
utilizing the granted authorization to change identification data.

The problem that DES points out is real; PAM is really too stupid
to handle the updating procss alone, and hasn't added the necessary
interfaces to correct the problem.  There was a very interesting
discussion of this issue with one of the main designers of the PAM
protocol that took place at one of the Silicon Valley get-togethers
hosted by the Netscape offices; the upshot of it was that Sun would
never be correcting the issue in an updated version of PAM in order
to be able to properly support Kerberos.


> Of course this won't work for certain legacy, read-mostly
> `authentication methods' such as NIS or Hesiod that aren't supported
> by PAM.

Kerberos has a similar problem.  PAM assumes that there is not a
requirement for a covert channel in order to update data in the
data store that's used for the purposes of authenticating identity
in order to authorize granting of rights.  It also assumes that
the identity doesn't li at the intersection of disjoint systems.

Most people who do not understand the fact that email systems use
forward and reverse lookups precisely because they can establish
non-repudiable identity as a result of an intersection of disjoint
delegation authroities, and ask "Why did you reject my mail on this
basis?!?" probably still aren't going to understand this.

All of this also ignores some ugly facts:

(1)	There is currently no support for separation such that a
	third party can proxy authentication on your behalf, if
	you are a primary party attempting to gain acces to a
	secondary party's resources.   Short of implementing a
	cryptographic pipe between the parties (which just moves
	the identity problem into the programs, rather than the
	humans and databases talking to them), this problem is
	very hard to adequately resolve.

(2)	To communicate between two programs on the same system,
	for example, a single interface module baeing used both
	to authenticate and authorize (e.g. login), and maybe
	audit events such that the logs are non-repudiable (we
	call this program "login") and another program that is
	intended to modify the data, and should probably inherit
	rights by virtue of the credentials running it rather
	than re-requiring them (we call this program "passwd"),
	UNIX systems have no way for the kernel to store and
	retrieve credential data on behalf of processes in a
	trustable fashion: it only has GIDs and UIDs.

For #1, you might be able to kludge up an interface; I personally
doubt it would be very secure.  For #2, you would need to change
the system substantially.

-- Terry