Subject: Re: BSD Authentication
To: None <current-users@NetBSD.org>
From: Peter Seebach <seebs@plethora.net>
List: current-users
Date: 09/08/2003 14:32:35
In message <200309081923.h88JNoY18443@srapc342.sra.co.jp>, Noriyuki Soda writes
:
>>>>>> On Mon, 08 Sep 2003 14:14:28 -0500,
>	seebs@plethora.net (Peter Seebach) said:
>> But everyone has been saying that it is *necessary* that a PAM module
>> be run in the caller's address space; that this feature is required by
>> real-world PAM modules.

>Yes. But with screensavers, "the caller" isn't a screensaver, but the
>wrapper program.

But then, in the cases where it's really the authentication client that
needs to be eaccessible to the PAM module, this *won't work*.

>> I did, and if it is correct that some PAM modules need to be able to
>> change the state of the caller, then those PAM modules cannot be run
>> under the setuid wrapper - they will not have access to the *actual*
>> caller.

>It seems you are misunderstanding here.
>PAM modules need to able to change the state of the caller, if
>it's called from programs like getty, ftpd, rlogind, rshd and telnetd.
>But PAM modules don't have to change the state, if ti's called from
>screensavers.

Why is this?  Keep in mind, it might be peeking into the caller's state,
not changing it.  Perhaps the PAM module needs to sneak a peak at some other
data structure.

>> A radius server.

>Thanks you.
>And in that case, does BSD auth provides better security than PAM?
>No.

Yes, it does.  The radius database can be restricted in access such that
a security hole in the radius server doesn't let you access the actual
radius database.

>In a configuration that BSD auth doesn't need root setuid root
>programs with a radius server, PAM doesn't need root privilege for
>the raidus server configuration at all.
>In a configuration that PAM needs root privilege with the radius server,
>BSD auth does need its setuid root module, too.

But the setuid module can be *a separate program*, keeping the root privileges
restricted only to the moment of authentication.

Or, indeed, it could be non-root.  You could have two user accounts:  One runs
the radius server, and nothing else, and has no access to anything anywhere.
One runs the radius database, and nothing else, and has access only to those
files.  If you break a hole in the radius server, you still can't read the
database.

-s