On Jan 26,  9:23pm, Peter Seebach wrote:
} John Nemeth writes:
} >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.

     I've been thinking about what you said...  I've come to the
conclusion that this argument depends on your point of view.  From the
point of view of the application, it really doesn't matter.  Everything
that is linked against the application must be considered suspect.  To
be truely safe an application must not link against any libraries
(static or dynamic) and make calls to the kernel directly.  Of course,
then it is stuck with the possibility of kernel bugs.  If it could
bypass the kernel, there would be the possibility of hardware bugs.
Since being this paranoid doesn't work (it would preclude having any
applications at all), the application just has to assume that the stuff
it is linked against works and is safe.

     Unfortunately, the above assumption isn't always a good one.  A
few years ago, a buffer overflow was discovered in syslog(3) on several
systems, which is a basic libc function.  Sendmail uses syslog(3) to
log information about messages it processes including the sender and
the recipient.  Some miscreats discover that they could craft addresses
that would overflow syslog(3)'s buffer and thereby get them a root
shell on a target system.  Now, Sendmail sanitises and limits the
length of log entries to prevent this.

     Keeping with the Sendmail theme, a couple of years ago, there was
a problem with the Linux kernel when they first started implementing
capabilities.  It seems that an application could disable the
capability to use setuid(2) in a child process.  People used this when
spawning a Sendmail process thus preventing it from dropping privs and
giving them a way to hack the system.  Now, Sendmail refuses to run if
it can't drop privs.

     In the hardware realm, there have been a number of problems, such
as Intel's (in)famous math bugs.  There is a bug in the UltraSparc 1
processor that will allow user applications to crash the system when it
is running in 64 bit mode.

     Given all these problems, an application really can't trust
anything about the environment in which it is run, therefore it really
doesn't matter what is linked against it.

     The other point of view is that of the system administrator.
Here, I will concede that you have a point.  With BSD Auth, an
application doesn't have to be setuid() unless it needs those privilege
for a reason other then authentication.  Also, you limit the contact
between potentially third party modules and applications.  This can
make things a bit safer.  Unfortunately, there are lots of third party
things that can be linked against an application, such as GUI
libraries, which can cause problems.

}-- End of excerpt from Peter Seebach