Why is this going to tech-kern? -current was fine, or tech-userlevel would
be the other good choice. ??

On Tue, 24 Sep 2002, Gary Thorpe wrote:

> --- Bill Studenmund <wrstuden@netbsd.org> wrote:
> > On Tue, 24 Sep 2002, Dan Melomedman wrote:
> > I can't say why loadable modules are part of the
> > design of PAM, but I do
> > know why a number of NetBSD developers want a
> > loadable-module system.
> > Because the other systems (well, not sure about CVM)
> > you mention above are
> > too limiting. The problem with a fork/exec model is
> > that, as I understand
> > it, all it can do is say yes or no. There are a
> > number of authentication
> > schemes that neem more than that. Like AFS, where
> > you need in-kernel
> > "tokens." These are kerberos credentials that AFS
> > uses. They must be
> > loaded IN THE PROCESS. No form of helper
> > authentication method can
> > substitute for that.
>
> So an authentication server cannot supply the
> credentials for the client to use?  If *file
> descriptors* can be passed via pipes (or am I
> mistaken?), I am sure something can be done, despite
> the "impossibility" of using a client/server model. A
> server can return MORE than yes/no. As far as I can
> see, tokens or credential would be stored as data and
> data can be sent via messages/requests.

Well, it depends on how you design the protocol. But the point is you have
to anticipate EVERYTHING that an authprotocol will want to do when writing
the protocol, AND you have to implement it. This means making arbitrary
subroutine calls and syscalls. And other stuff I haven't thought of.

We could do that, but I don't think we want to. It sounds very
heavy-weight when the goal was to be light-weight. Also, we either have
code around anticipating a protocol we don't know if will be used (often
derided as BLOAT), or we forget something.

Additionally, some protocols, like Kerberos, can work at not trusting
other processes on the box. AFS token generation doesn't need a server
process, it already is a client/server protocol. And with tokens, except
for the window when the token is being decoded and put into the kernel,
other mem-enabled users (like root) can't snoop what's going on (as far as
I can tell). So you can operate in a I-don't-trust-root-users mode. If we
have a local client/server, we have to trust that server, and can't do the
above. :-(

> > The problem with the client/server approach is
> > similar; you can only
> > perform methods expressable in the client/server
> > protocol. To try and do
> > something else, you have to change the client code.
> > Which means, without
> > dynamic modules, relinking everything. The whole
> > point is to try and be
> > able to add new authentication methods w/o
> > relinking, so that really
> > doesn't cut it.
>
> Only if the client/server protocol was poorly designed
> and non-extensible. I suppose OSes based on a
> microkernel should find it impossible to support AFS
> because in these EVERYTHING is abstarcted to message
> passing?

I don't think we want that full a message-passing protocol. While you're
right it could do everything, it sounds way too fat for my tastes.

> > Nope. While OK/FAIL will go a long way, there are a
> > number of auth systems
> > it won't do. And that's the whole point above. For
> > those systems, AFS in
> > particular, you also have to load credentials (make
> > syscalls()) IN THE
> > AUTHENTICATED PROCESS.
>
> A syscall may itself be implemented via message
> passing, although it is not done so in most systems
> including NetBSD. Perhaps the client/server model is
> incompatible with the way NetBSD works, but that
> doesn't mean that it is inherantly less capable. Is it
> REALLY a technical hurdle OR is it just "we don't do
> it that way"?

Do you really want to run programs that have that featurefull a c/s
language? You basically are handing control of every authenticating
program to the server daemons, and create an exteme potential for
vulnerability. Break one of those servers, and you have the system.

With loadable modules or a less powerful client/server protocol, the
authenticating programs are more secure. They know they will only do a
limited set of things in response to what the server says. But with a "I'm
telling you to do this system call" c/s protocol, how does the
authenticating program know if it should or shouldn't?

Take care,

Bill