[cap-talk] BitFrost : OLPC Security Architecture

[Toby Murray]

Following on from the recent OLPC discussion, the OLPC security
architecture has just been posted here:
http://dev.laptop.org/git.do?p=security;a=blob;hb=HEAD;f=bitfrost.txt

I haven't had time to read it properly but I received a pointer that it
might be borrowing a few ideas from the POLA/Capabilities community
after all.

There are hints of CapDesk, Plash, Polaris and Capability-based OSes
running through the following sections (the only parts of the doc I've
read so far) which are pretty tantalising:

> A program on the XO starts in a fortified chroot, akin to a BSD jail,
> where its visible filesystem root is only its own constrained scratch space. It
> normally has no access to system paths such as /proc or /sys, cannot see other
> programs on the system or their scratch spaces, and only the libraries it needs
> are mapped into its scratch space. It cannot access user documents directly,
> but only through the file store service, explained in the next section.
> 
> ...
> 
> Unlike with traditional machines, user documents on the XO laptop are not
> stored directly on the filesystem. Instead, they are read and stored through
> the file store service, which provides an object-oriented interface to user
> documents. Similar in very broad terms to the Microsoft WinFS design, the file
> store allows rich metadata association while maintaining traditional UNIX
> read()/write() semantics for actual file content manipulation.
> 
> Programs on the XO may not use the open() call to arbitrarily open user
> documents in the system, nor can they introspect the list of available
> documents, e.g. through listing directory contents. Instead, when a program
> wishes to open a user document, it asks the system to present the user with a
> file open' dialog. A copy-on-write version of the file that the user selects
> is also mapped into this scratch space -- in effect, the file just "appears",
> along with a message informing the program of the file's path within the
> scratch space.
> 
> Unix supports the passing of file descriptors (fds) through Unix domain
> sockets, so an alternative implementation of P_DOCUMENT would merely pass in
> the fd of the file in question to the calling program. We have elected not to
> pursue this approach because communication with the file store service does not
> take place directly over Unix domain sockets, but over the D-BUS IPC mechanism,
> and because dealing with raw fds can be a hassle in higher-level languages.
> 
> Benign programs are not adversely impacted by the need to use the file store
> for document access, because they generally do not care about rendering their
> own file open dialogs (with the rare exception of programs which create
> custom dialogs to e.g. offer built-in file previews; for the time being, we
> are not going to support this use case).
> 
> Malicious programs, however, lose a tremendous amount of ability to violate
> the user's privacy or damage her data, because all document access requires
> explicit assent by the user. 
> 
> ...
> 
> Certain kinds of software, such as photo viewing programs, need access to
> all documents of a certain kind (e.g. images) to fulfill their desired
> function. This is in direct opposition with the P_DOCUMENT protection which
> requires user consent for each document being opened -- in this case, each
> photo.
> 
> To resolve the quandary, we must ask ourselves: "from what are we trying to
> protect the user?". The answer, here, is a malicious program which requests
> permission to read all images, or all text files, or all e-mails, and then
> sends those documents over the network to an attacker or posts them publicly,
> seriously breaching the user's privacy.
> 
> We solve this by allowing programs to request read-only permissions for one
> type of document (e.g. image, audio, text, e-mail) at installation time, but
> making that permission (P_DOCUMENT_RO) mutually exclusive with asking for any
> network access at all. A photo viewing program, in other words, normally
> has no business connecting to the Internet.
> 
> As with other permissions, the user may assign the network permission to a
> program which requested P_DOCUMENT_RO at install, bypassing the mutual
> exclusion.


-------------- next part --------------
An embedded message was scrubbed...
From: "Murray, Alex" <Alex.Murray at dsto.defence.gov.au>
Subject: Actually looks like I'm wrong
Date: Thu, 8 Feb 2007 10:59:25 +1030
Size: 4930
Url: http://www.eros-os.org/pipermail/cap-talk/attachments/20070209/6a5924f7/attachment-0001.mht