[OLPC Security] Bitfrost vs. Rainbow

[Michael Stone]

Toby,

First, thanks for giving me such exciting reading material this evening.
I've run into Polaris before (many moons ago) but was not previously
familiar with the work of the Plash authors. You're certainly correct
that Rainbow bears the mark of similar design imperatives!

> I'm writing to enquire about the differences (if any) between the
> Bitfrost ideals and the Rainbow implementation.

Numerous; primarily caused by fear, uncertainty, and doubt about how to
proceed beyond the well established bounds of Unix discretionary access
control into the uncharted waters of network and X isolation. Jameson
pointed you to the right URL for the short summary; in response, you
should pose more specific questions for me to attempt to answer. (Or you
should read the source code, which is brief, mostly to the point, and
somewhat documented (for older versions) [1]).

  [1]: http://wiki.laptop.org/go/Taste_the_Rainbow

> In particular, the original Bitfrost documentation (e.g. [1]) suggests
> that it would be implemented using the VServer to control filesystem
> visibility etc.

We tried it last summer and discovered that the social expenses of the
route outweighed the gain. Then I took a hard look at the problem and
reached the conclusion that a "cheapskate" solution existed. Finally, I
documented the skeleton of that solution in the "rainbow.txt" link that
you cited.

> However, a quick look at relevant Rainbow docs (specifically [2])
> indicate that Rainbow might be implemented using only the standard Linux
> DAC mechanisms -- essentially, very similar to the Polaris design[3].

Correct to date, though we've basically reached the limits of the
existing DAC framework. Clever (or stupid, depending on your
perspective) hacks now seem to be required. For network isolation, I'm
currently intending to go forward with compartmentalized "network" and
"not-network" processes based on Dan Bernstein's sys_disablenetwork()
idea [2]. 

  [2]: http://cr.yp.to/unix/disablenetwork.html

For X, I'm still at the research stage, currently investigating both
XACE [3] and an off-the-cuff idea involving per-uid Xephyrs (or
similar tomfoolery).

(I've spent some time thinking hard about approaches based on selinux
and I'm simply unable to convince myself that we can afford the
cognitive burden of writing bespoke policy which can only be debugged by
SElinux hackers. Systems based on Unix DAC seem to avoid this problem
because the tools for debugging the DAC are well understood by a much
larger body of people and because the rules governing context
transitions are mostly static and mostly local (as opposed to global and
dynamic in SElinux).)

> Some more specific questions:
> 
>  - Does Rainbow use chroot?

No. The vserver implementation used chroot+read-only bind-mounts but it
greatly increased the complexity of the activity debugging process in
exchange for little obvious gain (in OLPC's default environment). I'm
happy to revisit this decision in the future if we discover
security-relevant discrepancies between my assumptions about how the XOs
will be used and reality.

>  - If so, how does its filesystem protections go beyond what Plash [4]
> offers?

In its present form, Rainbow appears to be quite comparable to Plash;
perhaps a bit weaker, and likely less well tested.

>  - In particular, Plash has some (or is close to providing) support for
> copy-on-write access, which is hinted at in [2].

We implemented CoW filesystem access based on VServer's CoW
link-breaking primitive but concluded on the basis of the prototype
that, at the time, we were unable to afford the required system
maintenance. (There was a particularly bad interaction between a race
condition in VServer's implementation of CoW link-breaking and the JFFS2
garbage collector which was eating filesystems during a release week.)

> Any info would be great.

Ask more specifically and ye shall receive. :)

> Finally, were one interested in hacking on Rainbow, what is an ideal
> development environment for doing so? (Particularly for someone without
> access to an XO).

Well, there are a couple of answers, depending on your tastes. First,
I'm extremely interested in cleaning Rainbow up to the point where it's
usable outside of OLPC's exact filesystem layout. If you're interested
in the same, then we might be able to work very profitably on getting it
running in whatever environment is most pleasing to you.

Next, there are several emulation environments. Marcus Leech is someone
good to talk to here about the trials and tribulations of OLPC's support
for emulated environments. (Again, it's an area in which we know we can
do better and in which we desire to do better. Outside folks who depend
on it and who make their voices heard when things break are extremely
valuable for making the whole system easier to deal with.)

Finally, you can request a machine through the developer program [2].

  [2]: http://wiki.laptop.org/go/Developer_program

Thanks for contacting us!

Michael

P.S. - It sounds like our goals are closely aligned with some of the
goals of the Plash project - also, OLPC has no desire to maintain
bespoke security software just for kicks. Can you suggest some an
approachable Plash developer (or mailing list?) to suggest that we
explore ways to further our mutual aims in concert?