--- Bill Studenmund <wrstuden@netbsd.org> wrote:
> Why is this going to tech-kern? -current was fine,
> or tech-userlevel would
> be the other good choice. ??

Sorry, I subscribe to both and I forgot to check which
list this was on.

> 
> On Tue, 24 Sep 2002, Gary Thorpe wrote:
> 
> > --- Bill Studenmund <wrstuden@netbsd.org> wrote:
[...]
> 
> 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.

Well obviously client/server schemes are not the vogue
for OS design (how many systems use it extensively?).
What is the best solution?

> 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?

> 
> > > 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.

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?

> 
> > > 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.

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.

> 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?

I don't know, its all academic anyway.

> 
> Take care,
> 
> Bill
> 



______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca