On Tue, 24 Sep 2002, Gary Thorpe wrote:

> --- Bill Studenmund <wrstuden@netbsd.org> wrote:
> >
> > On Tue, 24 Sep 2002, Gary Thorpe wrote:
> >
> > 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.
>
> Well obviously client/server schemes are not the vogue
> for OS design (how many systems use it extensively?).
> What is the best solution?

I think the best solution is to look at what we want to do, and see what
looks best. If that's client/server, so be it. There are a number of
protocols in development that are client/server. We just don't want the
whole OS to be client/server.

> > 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. :-(
>
> Why not? Do you trust your OS kernel? How about the
> dynamic linker?

I thought about muttering a paragraph on this earlier. You have to trust
your kernel, and your dynamic linker. No scheme will get around that. But
we have tools to help. For instance, you can install a system, and set the
immutable bits (man chflags) on the linker, the libraries, and your
modules. Then even root-processes can't modify the files. Upgrading means
going to single-user mode, but in multi-user, you can't get zapped.

With a generic client in each binary, you have to trust the running server
it talks to. It can get exploited and then all clients are opened up.
While there can (and probably will) be bugs in auth modules, they have to
get exploited each time you fire up the binary; you can't exploit once and
have the whole system (unless you can engineer the exploit to happen on
startup of a module).

Also, some auth methods, like Kerberos ones, already are client/server, so
adding an additional client/server step seems very strange to me.

> > 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.
>
> How fat are pure message-passing systems? Since NetBSD
> is not one of these, how much fatter would it make the
> OS to support such a scheme for authentication?

I have no idea. But I'm really leary of it since to do everything loaded
modules would do, you'd have to permit expressing arbitrary system calls
and subroutine calls, with arguements.

> > 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.
>
> Break the modules in PAM, same effect. Break dynamic
> linker, same effect. Having each process statically
> linked with all authentication methods is the other
> extreme and proabbly the least prone to vulnerability.
> However, it will be harder to maintain so trade offs
> are inevitable.

Yes, break the module and you have it. But the difference is that we have
tools to help with that (immutable flags, etc. above) while we don't have
comparable tools to keep a running program from being cracked.

Take care,

Bill