[cap-talk] What sustained interest in capabilities

[Mitsu Hadeishi]

Exactly.  Allow me to give a very simple example to illustrate the  
sorts of risks that can be mitigated by this design.

Suppose user A wanted to write a program (a program which only has  
access to the capability secure layer) that she wants to publish (as a  
service) to the world.  Perhaps this program gathers, say, restaurant  
ratings from the personal ratings databases of external users (let's  
call one of these users, user B) and compiles the aggregate ratings as  
a collaborative filtering service.  The program, thus, must have  
access to some of A's data (repositories of aggregate statistics), but  
the program also has access to user B's personal ratings.

If we were to build a system like this using role-based ACL security,  
we're immediately faced with some massive security issues.  What role  
does the program in question run under?  If it runs as user A, the  
program will not have access to user B's personal ratings.  If it runs  
as user B, it will not have access to user A's ranking databases.  We  
could run it as both user A and B, but that's the most insecure of  
all; user B would not be protected against the possibility that the  
program is a virus written by A, and user A would not be protected  
against bugs in the program that might allow user B to access, modify,  
or delete databases owned by user A that were not related to the  
restaurant ranking algorithm.

With capability security, as you all know, the problem is  
significantly mitigated.  In this case, you can simply give the  
program the capability to access user A's restaurant ranking aggregate  
database and no other document.  Even if the program has a bug, the  
worst it could do is mess up that one database and no other.   
Similarly, when user B chooses to run the program, he will have to  
give it explicit permission to access his personal ranking database.   
No matter how malicious the program is, it cannot read or modify or  
delete any other data owned by user B.

This same reasoning can be extended to shared libraries, of course,  
exactly as is the case with Caja.  A program could be written to use a  
shared library but only pass that library explicit capabilities it  
wanted to enable.  Thus, for example, you could run the library  
without giving it any capabilities to, say, make any outgoing TCP  
connections, or send email.  You can greatly limit the damage a given  
external library could do.

As for the inviolability of such a firewall --- of course there's  
always a theoretical possibility of such a firewall being breached.   
But in practice this is likely to be a relatively uncommon occurrence,  
whereas the risks associated with a role- and ACL-based design at the  
outer layer are extremely numerous.  How often has someone in practice  
managed to deposit foreign code, say, on one of Google's web  
services?  I'd say the answer to that is quite likely to be zero, and  
may remain zero for the foreseeable future.

Mitsu

On Jan 7, 2009, at 10:17 PM, Steve Witham wrote:

>> From: David-Sarah Hopwood <david.hopwood at industrial-designers.co.uk>
>> From: Mitsu Hadeishi <mitsu at syntheticzero.com>
>
> One way of thinking of Mitsu's idea is as a sandbox around the  
> capability-
> secure stuff (actually a metabox that sub-encapsulates all the
> objects inside).
>
> You would write the bulk of your software for this CS environment.
> The assumption is you write it in a CS style, even though you could
> emulate the problems of any kind of system in there.
>
> Compared to other ways of giving users access to (say) files
> and a MySQL database, through a middle layer of server-side
> software you're going to write, this at least lets the middle
> layer be more secure amongst itself, and lets you reduce the variety
> of ways it gets to the SQL server, filesystem and OS.
>
> If you didn't take other steps, many of which other system architects
> and server administrators ought to take too, you might well undermine
> any benefits of this tricky arrangement.
>
> It's not a layer of security added around or in the middle of an
> existing complex system, but an isolated place to put your
> new stuff (which you have to write in a better way) allowing the
> underlying system (and hopefully less of it) to be used in a less
> complex and variable way.
>
> It reminds me of an E vat, in this case talking to some
> software, files and OS services outside itself, still with their
> vulnerabilities but hopefully fewer of them exposed.
>
> So this layer can't "add security" to existing systems, but the
> idea adds a way to create more secure systems.
>
>  --Steve
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk