[cap-talk] Understanding capabilities in a web-desktop setting

Sandro Magi naasking at higherlogics.com
Fri Aug 8 10:32:57 CDT 2008


Luke A. Guest wrote:
> On Tue, 2008-08-05 at 10:41 +0100, Toby Murray wrote:
> I take it you mean that other pieces of software can't guess the URL?
> 
> If an capability URL has a large random string in there, you'll never
> get users to use capability systems; I know I wouldn't want to try and
> type in one of these URL's, or am I missing something?

Why would you be typing it in? How often do you really type in URLs 
nowadays without assistance, like auto-complete or bookmarks?

For instance, here's a link to a wiki:

https://www2897.ssldomain.com/higherlogics/www/Wiki.ashx/About

In it, you'll find a capability to edit the comments section:

https://www2897.ssldomain.com/higherlogics/www/Wiki.ashx/?key=airo-rgph-trwk

This capability is embedded in a link on a page I bookmarked, so there's 
need for me to remember it or type it in.

The random string in the query part of the URL constitutes the 
unguessable identifier which is mapped by the server to an underlying 
persistent object. This URL is unforgeable, and the possession of this 
URL is a necessary and sufficient condition for accessing the 
server-side object named by the URL. That makes it a capability.

> No, someone needs to write an idiots guide to capability systems without
> formal notation to get people to understand this stuff.

There are many introductions to capabilities without any formal 
notation. [1] is where I started years ago. If you consider a capability 
a key, like your car keys, but a key that can be easily copied (like 
embedding the above URL in this e-mail), that's a good place to start. 
Just keep in mind that there are capabilities with even stronger 
security properties than "capabilities as keys".

If you're a programmer, then a capability as an object reference is an 
even stronger capability than a key.

> My interest lies in OSes and providing a better security mechanism
> within one. So a few related questions here would be:
> 
> 1) What would be the process of logging on to a capability OS (assuming
> desktop or multi-user system rather than embedded)?

Any authentication method is usable in this context, with all the same 
weaknesses as in ACL systems. I described a more capability-like 
technique elsewhere [2]. I believe this method may have been discussed 
on this list in the past.

> 2) How does a user get these capabilities? I can only assume there would
> be the concept of a user and they would have a list of capabilities.

There is no concept of a "user" per se, there are only objects. One of 
those objects could of course model a "user" as in conventional systems.

For the above wiki, there are no users, there are only page objects and 
editor objects on the server. I hold the URLs/capabilities to all of the 
editor objects, and I've publicly exposed only a few page objects. One 
of those page objects embeds an editor object, so people on this list 
now have access to one of the editor objects.

How would you gain access to the numerous other editor objects without 
me granting you access, or compromising the server?

> 3) What would happen if you tried to access a website, would it bring up
> a ton of dialog boxes asking for permission, i.e. the Vista problem?

For the wiki, there are no authorization questions posed to the user. 
All authorizations are implicit by following the reference graph (the 
graph of links). So it is with capability operating systems.

Sandro

[1] http://www.eros-os.org/essays/00Essays.html
[2] http://it.slashdot.org/comments.pl?sid=446396&cid=22351928


More information about the cap-talk mailing list