[cap-talk] BitFrost : OLPC Security Architecture

[Stiegler, Marc D]

The indication that someone involved has seen and remembered at least
some portion of our stock presentation is this passage, oddly placed in
software installation:

399 To provide an example, consider the Solitaire game shipped with most
versions
400 of Microsoft Windows. This program needs:
401
402 * no network access whatsoever
403 * no ability to read the user's documents
404 * no ability to utilize the built-in camera or microphone
405 * no ability to look at, or modify, other programs

Hmmm....the solitaire program as an example of limited authority
requirements...hmmmm...:-)

There are nonetheless things that make me despair, as the preface to the
solitaire example: 

379 There is a very important distinction between two broad classes of
programs
380 that execute on a running system, and this distinction is not often
mentioned
381 in security literature. There are programs that are purposely
malicious,
382 which is to say that they were written with ill intent from the
start, such as
383 with viruses and worms, and there are programs which are
circumstantially
384 malicious but otherwise benign, such as legitimate programs that
have been
385 exploited by an attacker while they're running, and are now being
instrumented
386 to execute code on behalf of the attacker via code injection or some
other
387 method.
388
389 This difference is crucial and cannot be understated, 

Well, in fact, the difference is barely interesting, despite the
discussion that follows the above excerpt, which is an interesting
narrative in which all the words make sense but, for me at least, the
sentences do not.

--marcs 

> -----Original Message-----
> From: cap-talk-bounces at mail.eros-os.org 
> [mailto:cap-talk-bounces at mail.eros-os.org] On Behalf Of Toby Murray
> Sent: Friday, February 09, 2007 9:35 AM
> To: cap-talk at mail.eros-os.org
> Subject: [cap-talk] BitFrost : OLPC Security Architecture
> 
> 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.
> 
> 
>