Date: Thu, 04 Dec 2003 05:30:21 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: "Jacques A. Vidrine" <nectar@FreeBSD.org> Cc: freebsd-current@freebsd.org Subject: Re: NSS and PAM Message-ID: <3FCF36ED.9E1BEBC8@mindspring.com> References: <20031129011334.GC88553@madman.celabo.org> <20031201142737.GC99428@madman.celabo.org> <20031201175925.GC244@madman.celabo.org>
next in thread | previous in thread | raw e-mail | index | archive | help
"Jacques A. Vidrine" wrote: > On Mon, Dec 01, 2003 at 05:48:22PM +0100, Dag-Erling Sm=F8rgrav 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 use= r > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3FCF36ED.9E1BEBC8>