Re: The Perils of Pluggability (was: capability authentication)

[Jun Inoue]

On Tue, 11 Oct 2005 19:49:26 +0200
Bas Wijnen <address@hidden> wrote:

> > > > Actually, I think you have given a very nice example. All I really want
> > > > for this example is a system architecture that makes running *confined*
> > > > plugins so easy and efficient that it becomes the default approach used
> > > > by developers.
> > > 
> > > That sounds good.  Forking and dropping (almost) all capabilities seems
> > > easy enough for me.
> > 
> > ARRGGHH!! NOOOO!!! This design is how every UNIX server in history has
> > come to have holes!
> > 
> > No. The design you want is to start with *no* authority and provide
> > exactly what is needed. Trying to throw authority away *always* leads to
> > compromise.
> 
> Well, given the fact that you cannot get a capability back when you've dropped
> it, you're going to have to drop things you don't want to use, not "drop
> everything, pick up what you still need".
> 
> Of course, this should be done by specifying what you want to keep, not what
> you want to drop.

Wouldn't "drop everything, pick up what you need" be more natural?
If I understood it correctly, processes in general can be and are
created with an initial set of capabilities supplied by the parent (and
nothing else). Then in the "confined plugin" case, the plugin process
can be started with none of the parent's capability.  Except the parent
gives to the child, as the initial set of caps, what the parent thinks
the child needs.


-- 
Jun Inoue
address@hidden