Capabilities, Internet Style - Part 3

We all stand on the shoulders of Giants, in this case I'm relearning the lessons of the folks who wrote KeyKOS, CapROS, and EROS, which are capability based operating systems.

Dean Landolt has been giving pretty good feedback, and it's a good discussion going now. (It's fun!)

I said that a capability is stand alone, and gave an example of sending a capability in an email. Dean thought about it, and is discouraged by the implications he imagines when you apply it to a compound document

“Of course, this completely blows up the easy send-me-an-email capability described above. I haven’t worked through all the use cases in my head, but my guess is there room for both. But one thing I don’t want to do is reimplement the cascading nightmare that is administering a windows file share. Creating a system simple and clear enough for the average user to fully understand the implications of their actions is paramount.“

Now, if we were talking about ordinary Access Control Lists, yes it would be a nightmare, but we’ve got our shiny new “magic bullet” capabilities, so it’ll be a piece of cake. Trust me, and sign this purchase order. ha... just kidding.... ;-)

Use Cases are where to start to find out the implications of your models of things, and begin to flesh out details when you implement code. They provide the differentials to guide programmers when they reach forks in the road that could go either way. Dean provides 2 of them, sharing a bucket of blog entries, and editing portions of a compound document.

In either case, you want to take a capability and build finer-grain capabilities on top of it. Doing this with a file based ACL is impossible, because files are treated as atomic entries, and there’s no way to protect part of a file. Nobody ever thought it would be necessary to do so, and there’s no way to express the concept in an Access Control List.

Capabilities allow for arbitrary expression of rights to an extent limited by the capabilities of the programmer who implements them. Consider this thought experiment as an exploration of the expressivities of capabilities.

Let’s say I send an email something like this:

Hi Dean,

I got it working, I think... here’s version 0.001 of the server. I’ve got it up and running at http://warot.com/cap01

It uses a server at http://warot.com/cap01/cap01.asp, which is a simple ASP script I wrote to get things off the ground. It stores a single file in “content.txt” in the same folder. (so you can view it directly)

It’s a form (to start with)... it’ll take a token, and let you edit the file represented by the token (assuming it hasn’t been revoked)

What do you think?

--Mike--

Oh... yeah... here’s the token: [42]

Now, this really doesn’t do anything new, does it? No. Consider the next email:

Hi Dean,

Here’s version 0.001 of my first capabilities proxy... I’ve got it running at http://warot.com/proxy01, it requires uses a token you provide access the file store capability. It then lets you read/write, but only stores in UPPER CASE. Pretty weird, eh?

--Mike--

Now, this is a trivial example of vaporware in action, but does show something important. You can filter something by writing code ON TOP OF existing capabilities, without having give away the farm. The proxy in this case can only access the capability provided to it, so it CAN’T do anything outside than capabilities it’s provided. It can then provide a new service, a file store that doesn’t allow lower case letters.

I’ve just expressed a new thing... in a secure manner. Because you’re not at any point handing over a username/password pair, you don’t have to give away the keys to the kingdom. You only have to provide the keys to an object, or arbitrary portion thereof.

You can right proxies that you don’t have to trust beyond the capability you provide. Those proxies can then provide tokens with newly limited portions of the capability they posses.

Dean, you mention the nightmare of Windows administration (which is pretty much equivalent to any other ACL administration scenario), in this case the users themselves handle the distribution of a capability, and they CAN'T go outside of the original capability in scope or potential.

Instead of hoping that each and every piece of code makes all the correct security checks every time (leading to a combinatorial explosion when it comes time to test), you can start with the assumption of a capability, then test each level of delegation to make sure it works as expected. You only have to test one level at a time. This turns a nightmare in to a tractible problem.

I hope this makes sense.

--Mike--

Here are some references that I've been chewing on:

http://c2.com/cgi/wiki?CapabilitySecurityDiscussion intelligent discussion at the Portland Patters Repository

http://www.cap-lore.com/CapTheory/ - a new sight that I'm still plowing through, very helpful so far.