Re: BSD Auth

[SODA Noriyuki <soda%sra.co.jp@localhost>]

>>>>> On Tue, 19 Aug 2008 01:33:03 -0400,
      "Greg A. Woods; Planix, Inc." <woods%planix.ca@localhost> said:

>>> Previous discussions resulted in nothing really and PAM was blasted
>>> into the tree without taking into account any technical
>>> considerations.
>> 
>> Such summary is unfair.

> I think it's pretty fair.  No consensus was reached on the contentious  
> points

Hmm, the discussion was made at a mailing list that only netbsd
developers' can read/write it.  So you couldn't see it.
I agree the discussion should be done at public place, and I'm sorry for
that.  But the consensus was made there.

>> From some points of view, PAM is more secure than BSD Auth, and that
>> was one of reasons why PAM was choosed.

> I've never seen any real technical evaluation showing PAM to be more  
> secure.
> 
> Show me where the evaluation is.

See below.

>> With PAM, password attack can be only done via programs who already
>> own root privilege.  With BSD auth, anyone can do password attack.
>> For practical example, "pkgsrc/security/pam-pwauth_suid" implements
>> restriction that a user can try only his own password.  BSD auth opens
>> wider window against such attack.

> I'm not sure what you're trying to show here.  Your second two  
> sentences don't even seem to follow from the first two.

Let me describe again.

PAM uses traditional UNIX privilege mechanism to access password
database.  So, programs which already have root privilege can access
the password database (master.passwd).

BSD Auth uses multiple setuid-root modules to access master.passwd,
etc.  The module is placed on /usr/libexec/auth, and only users in
"auth" group can access the directory. (*1)

Think about X11 screen-lock program which tries to access user's
password.  As you know, X11 programs are big and may have a security
problem, so let's assume the screen-lock program has a hole.

With PAM + pam-pwauth_suid, malicious user only can examine the
password of the user who invoked the screen-lock program,
because the screen-lock program doesn't have any special privilege,
and only pwauth_suid_helper (really small program, easy to audit)
access the password.

With BSD Auth, the screen-lock program itself has "auth" group
privilege (*2), so if the program has a hole, malicious user can
examine all users' password on the local system (I mean brute-force
attack here).

Maybe you think that it's possible to use a program like
pwauth_suid_helper with BSD Auth too.
But that contradicts the design of BSD Auth.
The main idea of BSD Auth is to remove the privilege to access
password database from existing programs.  The mistake here is
that such programs (su, sshd, ...) usually already has root privilege,
so it's not worth removing the privilege at all except few exceptions
like screen-lock programs.
Such few exceptions can be easily handled by small helper program like
pwauth_suid_helper.  So, the effort of BSD auth to remove the
privilege is meaningless.

>> Another reason is that some features like Kerberos credential handling
>> cannot be implemented by BSD auth.

> Actually that's not true at all.
> 
> It may not have been done, but that's far from saying it's impossible.

The authentication module of PAM runs inside of the caller's process,
so it's possible to change the state of the process.
The authentication module of BSD Auth runs as a differnet process
from the caller's process, so it's impossible.

(*1)
If the permission of /usr/libexec/auth directory is incorrect, the BSD
Auth modules can be invoked by any local user.

(*2)
http://www.openbsd.org/cgi-bin/cvsweb.cgi/XF4/xc/programs/xlock/xlock/Imakefile?rev=1.7&content-type=text/x-cvsweb-markup
-- 
soda