[Cryptography] Do capabilities work? Do ACLs work?

[ianG]

On 15/02/2015 18:35 pm, Ben Laurie wrote:
> On 10 February 2015 at 12:52, ianG <iang at iang.org> wrote:
>> On 10/02/2015 04:59 am, Ben Laurie wrote:
>>
>>> As Bill points out, this is exactly the point of capability systems (he
>>> didn't say it, but it is what he meant). A long time ago we had a choice
>>> between ACLs and capabilities, and we chose the wrong thing.
>>>
>>> Capability systems do exist, but we also have a lot of ACL-based
>>> engineering to fix in order to properly use them.
>>
>>
>>
>> Having watched/worked with capability ideas for a while, I'm of the opinion
>> they don't work as well in practice as the theoretical pundits would have
>> it.
>>
>> Also, the users continue to demand ACLs.
>>
>> So my current view is that what is needed is a hybrid.  At a limited sense
>> one can see this with expiries:  a cap with a time limit on it is a cap with
>> a "control" on it.
>>
>> In a more developed sense, my software has lots of caps running around, but
>> servers that serve those caps also look at who's asking.  E.g., when Bob
>> looks at Alice's photo, the server only grants it if Bob is in Alice's A
>> list.
>>
>> This certainly makes for more complicated software.  But when the judge
>> asks, it's much easier to say "only Bob could have seen the photo" than
>> anyone with a cap...
>
> Tut tut - no threat model?

One threat outlined above:  when the judge asks...

The threat of being hailed to court might seem esoteric to 
cryptographers but it is pretty normal IRL.  Real people are threatened 
by real threats, not 1990s fighting-last-war myths like MITM, 
eavesdropping, CIA, etc.  Out in the world, the biggest threat is likely 
to be someone you trusted highly and has now turned against you.  Hence 
court is a big issue, and as a tactic in threat modelling, we can borrow 
from the lawyers:  "Imagine you are in court, how would this play out?"


> When you say "work" my immediate question is: for what?
>
> You talk about access to photos. I suspect you are right (having had
> this debate many times) that users (think they) want ACLs.

Right - it's mushy.  The way users think (or one version of that) is 
that they want their data to be secure from threatening people, and 
available to friendly people.  They can describe friendly, sometimes 
describe threatening, and we can simplify by saying anyone who is not 
friendly is not given access.

Of course, this is mushy, as outlined above, the judge.  It changes.  So 
the above protections aren't really enough, what do you do when the 
friend becomes the attacker?


> But they
> are not without their problems when you start thinking about more
> complex artefacts. For example, what about a document that includes
> (by reference) a photo. ACLs become annoying/difficult to understand -
> now some people can see the photo and some can't. Or when I change the
> doc ACL do I mean to change the photo ACL, too? Probably not (consider
> removing someone's access from the doc who previously had access to
> the photo, for example). Capabilities may not be as easy to understand
> for this case, but perhaps they work better.


Right.  So when we compose two separate rights over two distinct objects 
into one delivery, what are the ramifications?  It turns out ACLs aren't 
good at that, whereas caps are much better at least at the technical 
question of what that means.

However, the fact that we can successfully build these interacting 
resource constructs with caps more than ACLs doesn't mean the result is 
pleasing to users.

> But how about the other use of ACLs, namely on my own computer. In
> this setting ACLs make no sense at all - there is only one user: me.

Yup, in that the ACL system known as Unix users and groups was an 
artifact of 'departmental computing' more or less rendered dead by the 
arrival of the PC.  So, 1983 was 32 years ago, why does this keep coming up?


> What I really want from the system, whatever it is, is to protect me
> from all the evil s/w I am running. ACLs are a pretty poor fit for
> that purpose, and in many cases caps + designation-is-authorisation
> make far more sense and are much easier to deal with.
>
> The latter case strikes me as far more clear-cut than the former.

So, is that a context where you're designing a system / OS?

In my context, I'm designing a social network cum mobile money system, 
and I fully trust the (my) software.  What I don't trust is all the 
people hovering around near my user.  And sometimes I can't trust the 
user herself.

Meanwhile, I have to lean pretty heavily on Android to protect my 
software from all the other software.  Yes, big limits there, so when 
that breaks, we need defence in depth and ways to stem the damage.  But 
it turns out that statistically, users near my users are more likely by 
orders of magnitude to attack so I can pretty much let the defences 
against other people pick up the intra-android attack.

Someone recently made it very clear (Bill?) when the DoD person said, 
"no, you've got it wrong - we trust our people *because they've all been 
security-cleared* it is your software we don't trust."

Which war are we fighting again?  Who's war?


> Plus, as someone said earlier, Macaroons, which combine identification
> and delegation with traditional cap ideas, may be the best of both
> worlds.


Grass is always greener, of course.  I'll lay good odds they haven't 
even come close to solving the identification problem.

>> ps; a capability in the sense I mean above is implemented by an object which
>> is hashed canonically and stored somewhere on the net.  If you have the
>> hash, you can ask the store to reveal it.
>
> This is one way to implement capabilities for one possible use of
> them, but hardly comprehensive.


Indeed.  But, when talking about caps and ACLs it helps to have at least 
one concrete technology at hand, otherwise the conversation spirals into 
the theoretical.


iang