[Cryptography] Do capabilities work? Do ACLs work?

Jerry Leichter leichter at lrw.com
Tue Feb 10 17:49:12 EST 2015


On Feb 10, 2015, at 4:05 PM, Bill Frantz <frantz at pwpconsult.com> wrote:
>> 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.
> It is probably better to look at who is asking only when producing the audit trail. Otherwise you won't be able to handle the situation I mentioned earlier in this thread:
> 
>  For an example of the flexibility we need in our policies,
>  consider a real-world situation (from:
>  <http://www.hpl.hp.com/techreports/2009/HPL-2009-169.pdf>):
>  Alice, in a race to her next meeting, turns thunder-struck to Bob
>  and says, "Bob, I just remembered I need to get my daughter
>  Carol’s car to Dave’s repair shop. I’ve got to go to this
>  meeting. Can you take Carol’s car over there?"
There's a more fundamental issue here:  As engineers, we try to formalize everything.  But many human processes are not amenable to formalization.  They involve tons of assumptions about the way we interact.  If Bob doesn't drive directly to Dave's but takes a 10-mile detour to get lunch, most people would say that was well within the access Alice granted.  If he takes it on a 500-mile drive, because he always wanted to tour in a Porsche, clearly not.  If Bob brings along his friend Sam, that's fine.  If
Bob happens to be an Uber driver and takes along a paying passenger ... not so much.

The whole issue of authorization and who owes what to whom gets to questions that legal systems have been trying to deal with for thousands of years.  They have limited formalizations, but still needed judges and juries to deal with the edge cases.

I'd claim that a system that can really cover all these kinds of complications would be a fully-functioning human-level AI - and we would no more be able to formalize what it was doing than we could formalize what we are doing.

Computers have lead to a formalization of policies.  Anyone who's ever had to interact with an organization where policies are enforced "by the system" knows that what's lost immediately is the flexibility that humans bring.  Anyone who's worked in such an organization knows that human beings end up producing "hack arounds" because "the system" doesn't let them get their work done.  Does this introduce vulnerabilities?  Of course; but as in all things in the real world, it's a tradeoff.

Imagine a world in which your car would not let you violate any traffic law.  Do you think that would be workable?

Yes, we need more powerful ways to describe policies (and, more generally, business practices).  Yes, even more, we need ways to make the policies and practices we formalize comprehensible to and manipulable by human beings in a useful way.  (I can guarantee you that any organization that uses more than a couple of trivial ACL's cannot answer pretty simple questions about who has access to what resources.  In some ways, capabilities are *worse* - without significant help from the system, the kinds of questions we regularly ask - who could have read the file? - cannot be answered.  We as human beings are really bad at following chains of relationships.  This shows up for ACL's when you start nesting them - or worrying about what someone with Control access might be able to do.  For capabilities, "portability" is exactly the point, so you hit this much sooner and much more pervasively.)

But don't make the mistake of thinking that the goal should be to represent every trust and responsibility and authorization relationship.  That way lies madness.  In the old days, a bank didn't try to track access to each dollar bill or each account.  Stuff was controlled at a broad level, with dual controls for particularly valuable assets and - returning to the message to which I'm responding - auditing to catch violations.  That's a much better model than what we typically try to build these days.

                                                        -- Jerry



More information about the cryptography mailing list