Let me introduce some definitions:

  existing-BSD-Auth: BSD-Auth as it exists today.
  extended-BSD-Auth: BSD-Auth as it could be extended in future.
  unrestricted-PAM: PAM in which the module has unrestricted access to
        the context of the requesting process.  (For example, PAM as it
        exists today, implemented using dynamic loading.)
  restricted-PAM: PAM in which the module is allowed to do some things
        to the context of the requesting process, but is not allowed
        to do other things.  (This does not exist today, but could
        conceivably be implemented in future.)
  unrestricted-BSD-Auth: BSD-Auth in which the module has unrestricted
        access to the context of the requesting process.  (This does not
        exist today, and cannot reasonably be implemented in future.)
  restricted-BSD-Auth: BSD-Auth in which the module is allowed to do
        some things to the context of the requesting process, but is
        not allowed to do other things.  (Both existing-BSD-Auth and
        extended-BSD-Auth are in this class.)

On Sat, 13 Sep 2003, Jason Thorpe wrote:
> But you are NOT solving the general problem, which is that BSD Auth
> is fundamentally incapable of modifying the context of the process
> requesting the authentication, which is a capability that is sometimes
> necessary and which PAM has.

It's true that unrestricted-BSD-Auth does not exist, and that
unrestricted-PAM cannot be implemented on top of restricted-BSD-Auth.

However, a BSD-Auth-like mechanism *is* capable of making any
modifications of any kind that is planned for in advance.  This
is a feature, not a bug.  Some kinds of modifications are
already accommodated by existing-BSD-Auth (for example, setting
environment variables).  New types of modifications can be added to
extended-BSD-Auth, with amount of trouble (this is the "planning in
advance" mentioned above): you have to add a new message type to the
protocol spoken over file descriptor 3, and you might have to add new
syscalls to help pass credentials from one process to another.

restricted-PAM could be implemented over restricted-BSD-Auth, and I
suspect that that would be good enough for all but the most experimental
purposes.  Whenever you discover a new kind of modification that you
wish you could make to the calling process (but that you cannot yet
make), you:

  a) Add a new message format to the protocol that BSD Auth talks on
     file descriptor 3;
  b) If necessary, add new syscalls to deal with the data that will
     appear in the new messages;
  c) Add code in the BSD Auth library (which runs in the parent process)
     to parse and act on the new message;
  d) Add code in the PAM-over-BSD-Auth proxy to detect whether a PAM
     module has made the new change that you wish to allow, and if so,
     print a new message over file descriptor 3;
  e) Re-link all applications that care.  They were probably dynamically
     linked against the BSD Auth library, so simply installing a new
     version of the library (which was updated in step c above) will
     probably be sufficient.

I don't know enough about AFS to tell how difficult the above steps
would be, but surely they would be *possible*?  I can't tell whether the
people saying "AFS can't work over BSD Auth" mean "AFS can't work over
existing-BSD-Auth", or "AFS can't work over extended-BSD-Auth unless you
add new syscalls", or "AFS can't work over extended-BSD-Auth at all, not
even if you add new syscalls".  (Similarly for smart cards instead of
AFS.)

It seems to me that it's a security risk that a partially-trusted PAM
module (for which source code might not be available) is allowed to
scribble all over the address space of the requesting process.  Even in
a pure PAM world, without any BSD Auth, it would be useful to isolate
partially-trusted PAM modules behind a {restricted-PAM}-over-PAM proxy.
The proxy could run in a new process, let the partially-trusted module
do whatever it wants, and then the proxy could figure out which of the
things that are allowed to change have actually changed, and propagate
the changes back to the parent through a pipe.

A {restricted-PAM}-over-PAM proxy would look a lot like a
{restricted-PAM}-over-{BSD-Auth} proxy.  They might as well use the same
child-to-parent protocol (an extended-BSD-Auth protocol), and the child
part of the proxy might not even know whether its parent was being used
in a PAM or BSD-Auth environment.

--apb (Alan Barrett)