Subject: Re: BSD Authentication
To: NetBSD-current Discussion List <current-users@NetBSD.org>
From: Peter Seebach <seebs@plethora.net>
List: current-users
Date: 09/06/2003 02:47:37
In message <200309060706.h8676OxK018941@vtn1.victoria.tc.ca>, John Nemeth write
s:
>On Jan 18, 12:27pm, Peter Seebach wrote:
>} Dunno.  I wouldn't be surprised at all if the right thing to do were to
>} update libbsdauth to be able to pass the data from an authenticator safely...
>} Yes, this is more work than "we'll just let the authenticator scribble on
>} the stack", but it's also *safer*.

>     Considering that the client doesn't have any idea what libbsdauth
>is doing, how is this any safer then having a PAM module do things
>within the client's address space (at least from the client's point of
>view)?  Remember, a PAM module is just a shared library, just like
>libbsdauth will most likely be.  Actually, for your scenario above to
>work, it would have to be a shared library.

The difference is, *every* PAM module can have an entirely *different* set
of things it can scribble on.  With libbsdauth, once you've audited the
*single* libbsdauth (which isn't all that big), you're done - you know what
its capabilities are.  Each new module will necessarily be limited to that
set of behaviors.

>     No, we don't.  One of the things about PAM is that the client
>doesn't need to know anything about the magic being performed.  As far
>as the client is concerned, it all works exactly same no matter what
>authentication methods are being used and no matter what needs to be
>done to work with them.  If the client does have to know what is going
>on in the background, then something is wrong.  That wouldn't be
>scalable, since every client would have to be updated when a new
>authentication method was invented.

Only if the new authentication method needs access to local variables - which
it *shouldn't*.

Basically, PAM lets me do *anything* in an auth module.  Call setproctitle().
Spawn child processes.  Scan process memory space for interesting data and
save it somewhere.  Anything I want.

BSD Auth gives me a firewall between each new authentication method and the
program invoking it.  I *want* that firewall.  I don't want a new
authenticator to be able to change ANYTHING until I've considered whether or
not I *want* that to be changed by an authenticator.

If you don't know anything about the magic performed, you cannot possibly
trust it.  libbsdauth lets you put all the magic in one place; PAM makes every
module have its own set of security holes.

-s