Subject: Re: PAM
To: Dan Melomedman <dan%dan.dan@devonit.com>
From: Greg A. Woods <woods@weird.com>
List: current-users
Date: 09/26/2002 02:08:52
[ On Wednesday, September 25, 2002 at 21:40:13 (-0400), Dan Melomedman wrote: ]
> Subject: Re: PAM
>
> Greg A. Woods wrote:
> > That's a different problem. Static linked code does not require by
> > definition that the authentication be done in a separate process. A
> > separate process simply lends one a number of new features. Whether
> > those features are usefull or not depends highly on the circumstances
> > where and why a particular auth scheme is being used.
>
> Separate processes are needed for more than features.
I don't think you're saying anything different than I said except you're
making an additional claim which is not strictly true. No separate
process is _necessary_, just Anything which can be done with dynamic
loading can also be done with static linking (except PAM -- it
essentially requires dynamic loading by design, which is of course its
biggest failure, since if PAM were a framework which allowed runtime
pluggability for those willing to chance it and in a position of
desparate need instead of requiring it then the story might be
different).
The additional features I hinted at are indeed exactly the kinds of
separation of privilege and "runtime" flexibilities that you hint at.
However:
> Software not following these
> principals include Sendmail and BIND. Both are embarassment to the
> Internet.
Fundamentally the failures of BIND and Sendmail have nothing whatsoever
to do with their monolithic structure -- it's the domain of their
implementation which has made their implementations error prone, not
their basic composition as single long-running privileged processes.
After all the kernel is also a very large and hopefully long running
program with full privileges, even more than any user-land process it
services normally has.
Software written in plain C for Unix using the traditional standard
library, and especially using NUL-terminated strings carelessly, and not
following the principles of privilege separation and keeping the
privileged code as small and simple as possible will lend itself to
critical programming errors. The privilege separation is really only
necessary though because it's very hard to write safe and secure code
using C and the standard library. A mathematically proven correct
"system" could run entirely with the highest privileges and still be
trusted.
--
Greg A. Woods
+1 416 218-0098; <g.a.woods@ieee.org>; <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>