Re: BSD Auth

["Greg A. Woods; Planix, Inc." <woods%planix.ca@localhost>]

On 19-Aug-08, at 4:13 AM, SODA Noriyuki wrote:
> 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.

"Sorry" doesn't cut it here.

This issue is (still) a little too important.

Especially when it seems the decision was clouded with FUD and  
misinformation.  Perhaps it was just a case of ignorance is bliss?

As I said back in 2003:

You have also totally failed to show any _technical_ justification for
the PAM API.  Where is your evaluation?  What qualities did you compare?
What existing real-world applications using each API did you compare and
what metrics did you use to compare them?



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

Indeed -- that's one of the problems with PAM.  It doesn't offer full  
privilege separation.  Programs which don't need access to the  
password database never the less are given such access unnecessarily.


> 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)

Indeed -- with BSD Auth the privileges and access to sensitive  
privileged data is given only to those programs specifically designed  
and implemented to moderate access to that data as is necessary.

As I wrote here in 2003:

BSD Auth doesn't change the privileges necessary to authorize a process
as a newly authenticated UID -- it just retains the control over what
the authenticator module can do to the calling process and makes it
possible to separate the privileges needed for authentication from those
necessary to authorize a process thus making it possible to delegate
authentication privileges to a non-privileged UID and to then know that
no matter how buggy or compromised the authenticator is the best its
attacker can do, besides run other arbitrary foreign code as the
non-privileged UID, is validate the credentials of a specified username
without actually checking them.


> 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.

That's pretty funny -- so PAM still needs separate programs to achieve  
any level of privilege separation.

Pot, meet kettle.

So, what's the mechanism used here to assure that the process invoking  
this pam-pwauth_suid helper cannot also be used in a brute-force  
attack to guess other users passwords?


> 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).

If you mean "brute-force attack" then don't say "can examine all  
users' passwords".

I'm not an expert at BSD Auth internals, and especially not with the  
OpenBSD implementation, but I can assure you that technically there's  
nothing preventing BSD Auth from also using the exact same mechanism  
that the pam-pwauth_suid helper might use to avoid being abused for  
brute-force attacks against other processes.

Indeed if I'm not mistaken one of the "poster child" applications  
showing the benefits of BSD Auth is indeed the "screen locking" type  
of application.  See the thread from 2003.

It seems to me you're just spreading FUD, again.


> > > 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.

Indeed -- that's one of the HUGE problems with PAM -- it can change  
anything inside the context of the "caller's" process because it _is_  
the caller.  Worse, by choice of implementation it also requires that  
a process be able to modify even its text segment to load arbitrary  
other code which will then be given not just the same privileges the  
process already has, but also the very purpose of exercising those  
privileges and moderating the processes own authentication and  
authorization!

By your own admission the only way to avoid the full dangers of this  
issue is to implement helper programs just like BSD Auth does.


> The authentication module of BSD Auth runs as a differnet process
> from the caller's process

Indeed -- that's the whole idea.  Full and proper privilege separation.

> so it's impossible.

more FUD and mis-information.

As I said, it has already been shown clearly that BSD Auth can indeed  
be used to implement the necessary features required by AFS/Kerberos/ 
etc.

For example I wrote the following in tech-security way back in 2003:

Of course with AFS it would make a lot more sense to just write a new
BSD Auth authenticator which would directly use a new setpag_parent()
system call to authorize the parent process with the new credentials in
much the same way I hinted way back when I cited the paper describing
the similar system call used for OSF DFS.  I.e. with AFS there is no
real need to have the authenticator directly modify the calling process'
context -- those same index values for the AFS credentials can be safely
stored in any process context by a sufficiently privileged process and
that can be done of course without revealing the actual credentials to
the authentiator process.  After all the current hack is simply
modifying the groups list to stick the credential index(es) as integer
values at the front of that list and that requires root privileges and
thus root already handles exactly the same information it would need
handle to assign those credentials to any other process as I propose.
Ideally of course the credential pointers or indexes would be stored in
proper new struct ucred fields, not by overloading the groups list with
their presence.  (One could pass the credential index(es) back to the
parent via the environment variable trick already supported by BSD Auth
and then the caller could authorize itself before calling
setusercontext(), but that would require special AFS-specific code in
the client side of libauth or libc, which I gather we're trying to
avoid.)


--
                                        Greg A. Woods; Planix, Inc.
                                        <woods%planix.ca@localhost>