[cap-talk] Unestos paper notes (was: Re: More Heresey: ACLs not inherently bad)

[Toby Murray]

On Mon, 2008-09-01 at 07:44 -0700, Jed Donnelley wrote:
> At 01:27 AM 9/1/2008, Toby Murray wrote:
> >Capabilities need not be inherently more difficult to understand than
> >conventional Unix semantics in order to "flummox application designers",
> >but merely be less widely employed...
> 
> I appreciate this argument.  However, I've seen programmers deal with
> so many different and even awkward situations (in which class I don't
> consider OCap programming) without suggesting that they are "flummoxed"
> that it surprises me to hear that word used by anybody who actually
> did capability or strict object programming.  Perhaps I just have a
> higher standard for flummoxing programmers.
> 
> I'd like to hear more about the programmers who were actually so
> flummoxed and the situations they found awkward.

Fair enough.

> > >   They continue:
> > >
> > > "Instead, we advocate a per-process, Unix-style namespace...
> > >
> > > I don't understand what is going on in the above.  Are they advocating
> > > that the kernel support separate Unix-style name spaces for each
> > > process?
> >
> >Yes, I believe so.
> 
> That seems a bit heavy handed to me.  I don't see what value it
> adds beyond a per directory flat name space.  With a per directory
> flat name space one can create a hierarchical "Unix-style" name space
> with the use of multiple directories with what to me seem fewer issues
> with mechanisms like "mounting".

I don't follow your description here of a "per directory flat
namespace". Could you elaborate?

> > >   When they suggest that P1 'mount' /secret/bob as the directory /home
> > > in P2's name space it seems to me they are overreaching a bit.  Why
> > > should P1 control names in P2's environment.  To me it seems more
> > > effective for P1 to simply send a "capability" to /secret/bob to P2.
> > > P2 can "mount" it anywhere it wishes.
> >
> >Sure, but the traditional UNIX API has no means to represent such a
> >capability.
> 
> I thought the file descriptor served as such a capability.

Righto. I take your point.

> >I'm not convinced of the need for this part (MAC) either. That's why I
> >referred only to Unestos and not Asbestos when bringing this up.
> 
> Do you believe that when they say 'MAC' in this paper they mean more than
> what we typically refer to as 'confinement'?  From my read of the paper it
> wasn't clear.

>From memory they were talking about data labelling, right? I suspect
this allows one to express things more directly than can be expressed
using a confinement primitive, but I'm not sure. At either rate, this
sort of thing has not been proven to be necessary to implement the sort
of POLA that would help an ordinary desktop user. Hence, I see it
largely as a distraction.

Cheers

Toby