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? _______________________________________________ Security mailing list [email protected] http://lists.laptop.org/listinfo/security
