Subject: Re: BSD Authentication
To: Noriyuki Soda <soda@sra.co.jp>
From: Greg A. Woods <woods@weird.com>
List: current-users
Date: 09/08/2003 16:34:24
[ On Tuesday, September 9, 2003 at 01:34:17 (+0900), Noriyuki Soda wrote: ]
> Subject: Re: BSD Authentication 
>
> Anyways, PAM can reduce the number of setuid programs more than BSD auth.
> (If we provide one setuid wrapper for programs like xlock).
> Because PAM itself doesn't need any privilege promotion like BSD auth.

I think that's a very naive view of things.  Ultimately authentication
checks must be done with some form of special privilege if they're to be
done securely since only a privileged process can make such decisions
for the system as a whole.  If one wishes to delegate these privileges
to a specific virtual identity, as OpenBSD do with special group
privileges for accessing secret keys or whatever, then that's a "Good
Thing(tm)", not a bad thing.  Separation of privileges so that only one
very tiny and very simple program need run with those enhanced
privileges is also a "Very Good Thing(tm)".

(note there are two different things mean by "privileged":  (1) there's
the fundamental privilege of running as UID==0; and (2) there's the
privilege of running as a user that has been delegated rights to
specific resources such as secret key databases or whatever)

> Anyway, the reason I prefer PAM is simple.
> 1. We need PAM anyway, for compatibility with other UNIX.

Really?  Who really needs this level of compatability?  Why?  How big a
percentage of current and potential users need this level of
compatability?

Furthermore since NetBSD is an open source system, why can't all those
requirements currently fulfilled by PAM support in other systems be
directly integrated nicely into NetBSD without the need for maintaining
any sort of PAM compatability?  For example this is what I've suggested
for AFS.  If AFS is to be integrated into NetBSD then the right way to
do it is to re-design its OS interface in such a way that it works well
within the unix security model (even if that means keeping the ability
to give different process groups different credentials :-).

So far there's been absolutely nothing shown in PAM that can't be done
better, and more securely, with BSD Auth.  The only thing PAM alone can
do is support binary-only (object-only) pluggable authentication modules
written specifically for PAM and distributed only in that form.  However
we know for certain that's currently not a necessary feature for any
existing NetBSD users or else they wouldn't be using NetBSD already, and
most of the arguments that have been put forth suggesting this could be
a future requirement of existing users, or that it would gain a larger
market share, have been so full of smoke and mirrors that it's
impossible to know if there's any truth or substance to them at all --
even time cannot tell unless we can split the universe, run each down a
different path, and monitor each variant from the other.

> 2. If we implement PAM over BSD auth, some third party PAM modules
>   may stop working, because some PAM modules may require the feature
>   that they can change the state of the caller process.

That's also a "VERY Good Thing(tm)".

Besides, anything that stops working can be fixed and worked around
after some careful thought planning.  Pretending that PAM over BSD Auth
is unworkable because it _may_ break something is ludicrous.  Let's find
out what might break and find some innovative and yet still-secure way
to deal with it sensibly!

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>