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

[Toby Murray]

On Tue, 2008-08-05 at 10:54 +0200, tsr wrote:
> I've finally decided to really get to work on one of my dream projects
> of the last couple years: An online open-source multi-user
> PIM+/web-desktop with exceptional security.

> I'm having trouble finding positive information on capabilities so I
> can't really say if it's feasible to implement it at this level.

Hi,

Let me assure you that it is possible to implement in a capability-based
[*] manner. Moreover, the tools to do so already exist!

The *only* thing that makes a system a "capability system" is this:

 - A system is a capability-system if and only if:
     1. The only way for one entity in the system to interact with
another is if it can "name" that entity, and.
     2. Names cannot be forged. 

For example, in a capability-based programming language, one object can
call methods on another if and only if it has a variable in scope that
refers to that other object. Variables take on the role of "names" here.

In a web-based capability system, URLs take on the role of "names". To
make them unforgeable, these URLs contain a large random string. Then
entities can access a resource/object if and only if they have a
(non-guessable) URL that refers to that resource/object.

So, how might you built your web-based desktop?

There is already a distributed capability-based desktop, called CapDesk
[1], that has been implemented on the capability-based language, E [2].
The basic idea behind CapDesk is this:

- Each desktop application runs with the least authority required to
perform its job. 

For example, when you double-click on a text-file file to open it in a
text editor in CapDesk, the text editor is given the authority only to
read that one file, and nothing else! Any vulnerabilities in the text
editor do not make the rest of the system vulnerable!

The basic CapDesk design can be emulated on the web. The E language, in
which it is implemented, allows objects on one machine to call methods
on objects on another machine by using unguessable URLs that refer to
those remote objects. Hence, it has many similarities already with the
web-based approach.

Now if you were going to emulate some of the CapDesk ideas on the web,
your best bet might be to implement your system in Caja [3]/Waterken
[4]. Caja is a capability-based version of JavaScript. Waterken is a
system that allows JavaScript code (running in the browser) to invoke
methods on remote objects (running on a server, and usually written in
Java) by using unguessable URLs to refer to those objects, like E. You
can go even further and write your Java objects in a capability-based
version of Java, known as Joe-E [5]. Then one server-side object can
access another only if it has a reference to that object. Hence, you get
excellent security even *between* the server-side objects.

So you could write a desktop "server" in Joe-E, that maintains a
collection of Java objects that represent things like files,
applications etc. You could then write your desktop shell in Caja, using
Waterken to allow the Caja code to call methods on the server-side
objects.

Because Waterken, Caja and Joe-E are all capability-based, you
*automatically* (without having to do anything at all!) get a
capability-based desktop that ensures that any object in the system
(including the user shell, or various server-side objects) can access
another if and only if it has an unguessable name that refers to that
object.

The system, then, it completely internally mutually suspicious -- no
part of the system need trust another very much, since no part of the
system has very much power. Yet it all hangs together nicely. (see
CapDesk if this sounds hard to believe.)

Someone really needs to write a "getting started with building
capability-based web applications" article that shows how to hook up
Caja, Waterken and Joe-E to enable one to easily write distributed
capability-based web applications by leveraging the natural synergy
present in these three technologies.

I hope this gives you something to have a look at to get started with.


[*] What I'm calling "capability-based" above, is more commonly called
"object-capability" in the modern literature, but I wanted to avoid
introducing a new term that wasn't otherwise necessary.

[1] CapDesk http://wiki.erights.org/wiki/CapDesk

[2] E http://wiki.erights.org/

[3] Caja http://code.google.com/p/google-caja/

[4] Waterken Server http://waterken.sourceforge.net/

[5] Joe-E http://code.google.com/p/joe-e/