[cap-talk] Horton vs. ACLs (was: Examples where ACLs are better...)

[Jonathan S. Shapiro]

On Mon, 2007-10-08 at 10:38 -0700, Mark Miller wrote:
> On 10/8/07, Jed Donnelley <capability at webstart.com> wrote:
> > What I was referring to was Jonathan's concern that the Horton
> > mechanism which I believe does qualify as a 'membrane approach'
> > has "...storage allocation and transitivity issues that were very
> > difficult to resolve without GC."
> >
> > Do you know what he means there?
> 
> GC stands for Garbage Collection.
> 
> Systems like E, where allocation and GC are implicit, are vulnerable
> to denial-of-service by resource exhaustion attacks.

On the plus side, these systems can automatically reclaim unused storage
as objects become unreferenced.

> For ocap systems like KeyKOS, EROS, CapROS, Coyotos, GuardOS where
> right to memory is a first class right and the kernel does no implicit
> allocation, we do not yet have practical proposals for membrane
> mechanisms, whether for use by Horton or even for non-kernel remoting
> systems like DCCS. I have heard no proposal for non-kernel remoting
> systems that are invulnerable to memory exhaustion attacks.

To be clear: I would be happy with a solution in the local-only case.

The issue is less allocation than de-allocation. The problem in an
explicitly deallocated storage system is that you are forced onto a
design fork:

  1. Accept that deallocations will break membrane transitivity
     in ways that we do not intend/want.

  2. Accept that the allocations will need to be managed centrally,
     which leads immediately to "free rider" concerns.

There are also performance concerns, but with care I think those can
probably be managed. The problem here is very broad: prompt, explicit
reclamation plus sharing = durability failure.

> > Aside from any use Horton sorts of mechanisms may have in modeling
> > hybrid systems, I would like to better understand the concerns that
> > Jonathan is expressing about the unsuitability of Horton to
> > practically achieve the auditability value of ACL systems
> > in a pure object capability context...

Since Jonathan didn't raise any such objections, Jonathan would be
interested to know about them also.

But just to be clear whether we are looking at the same problem, let me
attempt a zero'th-order attempt to state the problem.

The audit problem is to provide a mechanism by which an external
security auditor (a human using tools) can determine which programs have
access to which authorities.  There is an intrinsic conflict between the
desire for and utility of private namespaces and the desire for and the
importance of auditability.

I am not aware of anything in Horton that addresses the namespace issues
one way or the other -- the namespace problem seems largely orthogonal
to the low-level ACL problem.

> 
> The only objection I've heard about Horton so far is storage
> management. This is a serious objection, but doesn't contradict any of
> the claims made in our paper.

It wasn't intended to.
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC
www.coyotos.org, www.eros-os.org