[cap-talk] More Heresey: ACLs not inherently bad

[Jonathan S. Shapiro]

On Thu, 2008-09-18 at 18:09 +0100, Toby Murray wrote:
> On Thu, 2008-09-18 at 12:28 -0400, Jonathan S. Shapiro wrote:
> > On Thu, 2008-09-18 at 08:52 -0700, Charles Landau wrote:
> > > I take you to mean, the challenge problem does not specify a
> > *policy* 
> > > for changing permissions.
> > 
> > Indeed.
> 
> I can't see how this challenge is different from saying, "I want to
> support arbitrary access policies for a group of users on a graph of
> objects atop a pure capability system." Without tying it down somewhat...

Toby: I *have* tied it down quite a bit -- more than enough (I think)
for people to be able to look at the problem.

I'm perfectly comfortable with a response that starts with "Here is an
example problem that falls into that category, and here is how we might
solve it." But I am intentionally trying to pose a question about a
*class* of access policies involving the common elements of a shared
graph structure and non-shared permissions.

> the answer to your question will uncontroversially be "We can't do
> everything, but none of us (yourself included) have ever tried to argue
> that we can. Why care now?" 

That's not the question. The question is can we do *anything* along
within the class.

> What we can do that mimics ACL functionality (e.g. Membranes, NDAs etc.)
> we know are obviously less efficient. Fair enough. Hence, even if we
> could do arbitrary policies, I expect the answer would be again
> uncontroversially that they would be grossly inefficient when compared
> to their ACL counterparts.

I agree. And the issue that I am trying to explore with the challenge is
whether that is good enough. In the presence of a common use-case whose
real-world requirements are non-contrived and demand separation of
designation and authority, we must either solve the efficiency problem
or acknowledge that capabilities are not a practical universal substrate
and then figure out what to do about that.

Actually, I'm much more concerned about storage than efficiency at this
point.

And I will add that I *do* see a viable capability-based implementation
for a whole bunch of interesting problem instances here. That
implementation does not appear to suffer from the problem of membranes,
but it does, in effect, precisely model ACLs.

Which brings me to my *real* point, which is that ACLs appear to cover a
real-world, non-contrived, and valuable use case that capabilities do
not. ACLs may not be the only mechanism that does so, and they may not
be the best mechanism for doing so, but it appears to me that *any* such
mechanism must separate designation and authority, and if that is true
then capability systems are either pure or practically viable, but not
both.

> The counter-point to this comes from the first talk I gave on the NDA
> paper you reviewed for JCS. At the end, someone asked "If you're
> replicating ACL functionality, won't you re-create all of the problems
> they entail, such as the complexity of namespace management, loss of
> POLA, etc?" to which I could only answer "Yes". This is important to
> remember.

Agreed. And given the requirements I have put forward, it is clear that
the problem demands that those issues be accepted (though possibly
sandboxed). As a practical matter, I actually think that we can do much
better than straight ACLs here.

> We know that capabilities provide much better
> support for things that are far more important than supporting arbitrary
> policies, such as POLA and writing secure programs.

Perhaps. But we also know that capabilities cannot succeed if they
cannot handle common use cases.

>  These are things we
> need right now and are surely much more important to the current threats
> we fact than supporting access control policies that we can't even
> articulate. (My counter-challenge to you is to articulate a particular
> access policy, or a family of such policies you want to be able to
> enforce, see ;)

Well, since I've articulated that class of policies multiple times now,
the burden rests on you to identify what it missing that you need to
know.


shap