Subject: Re: BSD auth for NetBSD
To: Noriyuki Soda <soda@sra.co.jp>
From: Greg A. Woods <woods@weird.com>
List: tech-userlevel
Date: 09/14/2003 14:11:08
[ On Sunday, September 14, 2003 at 09:08:10 (+0900), Noriyuki Soda wrote: ]
> Subject: Re: BSD auth for NetBSD
>
> And as I alreday wrote, this is the point where I think BSD auth
> made a mistake. Actually there is only very few number of such programs
> except screensavers. And the problem of screensavers can be fixed even
> with PAM easily.
Well I don't know about all screensavers, nor do I know about all PAM
implementations, but I do know that pkgsrc/x11/xlockmore with PAM
support will want to run with enough privileges to read the shadow
password file (spwd.db, /etc/shadow, whatever) so that the PAM code can
read the encrypted secret, thus meaning any bug in a PAM-ified xlockmore
can lead directly to rogue code reading the whole shadow passsword
database. The fact is such bugs have been frequent and exploitable in
xlockmore, partly due to the fact that a full implementation of it pulls
in more third party library code than almost any other single X11
application known to man. Think about it. The PAM code must somehow
directly read the shadow password database in order to access the
encrypted secrets. This means that for a time there will be an open
file descriptor for that database. At this point it's irrelevant
whether or not the PAM code has to run as root or just as whatever
unique group-ID one might think it is safe to use to access the shadow
password database.
The fact is it is _never_ safe to allow anything but UID==0 to access
the shadow password database, at least not so long as the (even)
encrypted secret for the superuser resided in that same database.
> So, actual number of setuid programs may rather increases with BSD auth,
> due to its authentication modules.
You are mistaken. BSD Auth is not mistaken.
BSD Auth really does reduce the number of setuid programs which may be,
and/or are commonly, invoked directly by users.
Note the very important caveat: "invoked _directly_ by users".
The problems for screensavers and everything else which starts its life
running as a normal non-privileged identity, is also easily be solved
with BSD Auth without ever giving the likes of xlockmore process direct
access to the shadow password database (just as well as Crys SASL solves
the same problem for similar non-privileged applications as well). With
BSD Auth (as with Cyrus SASL and saslauthd), the process with access to
the shadow password database is completely isolated from the process
requesting authentication services and no rogue or exploit code in
something like xlockmore can ever do anything more than what any idiot
at a "login:" prompt can do.
So, anyone who claims PAM is in some way technically superior to BSD
Auth is really right off their rocker! No authentication code which
runs in the context of the caller can ever be considered "technically
superior" to BSD Auth, and that includes good old getspw*() and crypt().
--
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com> Secrets of the Weird <woods@weird.com>