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

[tsr]

Toby Murray escribió:
> 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. 
>   
Thanks, I think this was the kind of information I was looking for. A 
simple explanation of the essence of capabilities.

As for the rest of the post, I'm looking into it and I really appreciate 
all the information and links. This kind of stuff is really what I have 
been having trouble finding. In the end I will probably start with using 
something more generic for two reasons first to really teach myself to 
think in terms of capabilities and second access to more generic set-ups 
comes easy and I don't have to think about it. In the end I have no clue 
where I'll end up though.
> 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/
>
>
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>
>