[cap-talk] OLPC talk - implications of cap-like security?

[Ivan Krstić]

On Jul 1, 2007, at 1:45 AM, Mark Miller wrote:
> I watched your talk, which I quite enjoyed. My compliments.

Thanks!

> you refer to a "bitfrost specification". Has an actual spec been
> posted yet?

As someone pointed out, I was referring to the architecture-level  
spec (there's a nicer-to-read version of it at <http:// 
wiki.laptop.org/go/OLPC_Bitfrost>), not the implementation one. The  
latter was scheduled to be done a while ago, but for a number of  
reasons, the implementation details ended up strongly fluctuating  
until just very recently. I posted a status update on the security  
implementation two days ago to the OLPC development list:

     <http://lists.laptop.org/pipermail/devel/2007-June/005622.html>

With that finally unblocked, writing an implementation-level  
specification is back in my queue but the realities of our schedule  
mean it's no longer possible to produce one before we ship the  
laptops, unfortunately.

> I'm curious to know what you mean by "object store" above.

We want to preserve the use of files as binary blobs as is common  
today, but we also want for there to exist a rich centralized (system- 
wide, file format-independent) metadata layer on top of that. So we  
have an object store that keeps track of all the files on the system  
in an embedded database, allowing for versioning, tagging, and so  
forth -- while still mapping those rich metadata records to actual  
file blobs. This is very similar to what any version control system  
does, really, except we're making it more featureful and managing all  
the files on our machine in this way.

Now, when an application asks to open a file, the user is asked to  
choose not a filename from a filesystem but an object from a  
hierarchy-free store; the object can be a picture, a chat transcript,  
a text document, a web page, an e-mail, etc. The application can  
specify only wanting to open a particular kind of object, of course.

The way an application asks to open a file is to send a message  
through D-BUS (purely an IPC mechanism) to the object store, which  
gets a trusted chooser ("powerbox") shown to the user, and then  
materializes the file blob for the object of the user's choosing in  
the application's directory space. Finally, it sends the application  
a message telling it the filename that just appeared in its space and  
also allowing access to the corresponding metadata record.

> Do you use D-BUS for communication between mutually suspicious
> processes? Do you treat D-BUS object "names" as unguessable (sparse)
> capabilities?

Suspicious processes -- user applications, termed 'activities' in  
OLPC-speak -- can only communicate with system services. They cannot  
communicate with one another, or even see that other suspicious  
processes are running or such applications installed. For all any  
activity knows, it's the only program installed on the machine aside  
from the operating system.

> It occurs to me that Plash <http://plash.beasts.org> may already solve
> many of the same problems you're facing. AFAIK, it uses Unix Domain
> Sockets for inter-process communication, so it can use file
> descriptors directly as object-capabilities. Have you looked at it?

Yes, I'm aware of Plash. In some ways, Bitfrost is solving a far  
wider problem than sandboxing FS views: we also want network  
isolation, resource consumption constraints, variable granularity  
(not just per-process), etc.

> I like your choice of VServer for what you're doing. But every time
> you use the term "VM" to describe it, I get confused and then have to
> remind myself: "He means virtual operating system, not virtual
> machine." If it were a VM, then I could run different OSes in
> different VMs.

A bunch of the VM people I talk to refer to containers as "container- 
based VMs". I've devolved into saying VM because most people I talk  
to aren't familiar with the idea of containers.

> Can VServers within one host Linux communicate with each other using
> Unix Domain Sockets? If the answer is currently "no", how easy would
> it be to fix this?

Sure, if you let them.

Cheers,

--
Ivan Krstić <krstic at solarsail.hcs.harvard.edu> | GPG: 0x147C722D