Rainbow
Translate this page with Google -español -български -中文（中国大陆） -中文（臺灣） -hrvatski -čeština -dansk -Nederlands -suomi -français -Deutsch -Ελληνικά -हिन्दी -italiano -日本語 -한국어 -norsk -polski -português -română -русский -svenska
Introduction
Rainbow implements the isolation shell implicitly described in the Bitfrost security specification. This means that it isolates activities (and eventually system services) that it is asked to run from one another and the rest of the system.
Rainbow implements this isolation by generating a new uid (and perhaps a new gid) for each program it is asked to run. Running each activity as a separate user means that standard Unix access checks can be used as the primary 'gate' to control the visibility of activity-driven side-effects like reading from or writing to files or devices or signalling other processes.
For Activity Developers
When the user asks Sugar to start your activity, Rainbow is the software which actually asks the Linux kernel to do the 'starting'. However, in order to achieve the security goals described in Bitfrost, it places some restrictions on your software. You can find out more about these restrictions in the low-level activity api documentation. (In the future, the Sugar almanac may also contain some similar information).
Disabling Rainbow for Testing
Rainbow can be trivially disabled by running
rm /etc/olpc-security
as root. It can be re-enabled by running
touch /etc/olpc-security
also as root.
Design and Implementation
Rainbow has been implemented according to three designs to date.
0.8-series
The 0.8 series is designed as an "exec-wrapper". The "rainbow-run" wrapper is receives control from the shell, performs any requested isolation steps, then hands control over to isolated program. This way, rainbow can be used from freedesktop.org .desktop launcher files, from the command-line, and from custom graphical shells like Sugar with equal ease.
0.7-series
The 0.7 series was designed as a privileged [[1]] daemon. Sugar calls into this daemon when it wants to launch activities. An advantage of having a daemon is that the daemon can cache the results of expensive computations like python module loading. The problem with the daemon is that it consumes extra memory and that its caching behavior can cause many frustrating bugs.
vserver-series
The first implementation of rainbow (and of olpc-update) used a containerization technology called VServer to implement extensive isolation including network and CPU usage limits. Unfortunately, these early implementations revealed fundamental race conditions in the custom vserver patches provided to OLPC and the OLPC kernel team was unwilling to support the patches. Michael Stone created a new design outline, written up in rainbow.txt which explained how Bitfrost could be approached without vserver and vserver was removed from the kernel.
Testing
Automated
See test-rainbow. This code sets up a mock chroot in which rainbow can be tested, then runs a small multi-user test script.
Fedora
# on rawhide: yum install rainbow ...
Ubuntu
Bernie's PPA contains some basic rainbow packages which you can install.
jhbuild
# TBD; talk to Sascha Silbe for help.
SoaS
# TBD; talk to ??? for help.
Filing Bugs
General instructions are available on how to report bugs.
Coding
Rainbow needs your help to be awesome. Some broad ideas on how to make it more awesome are described in the #Next Steps section. In the short term, though, the best way to help is to test it, to file bugs, and to help get it packaged in more distributions.
Packaging
Please bring Rainbow to your favorite distribution. (So far, Rainbow is available for Fedora and, via bernie's PPA, for Ubuntu Jaunty.)
Next Steps
- Accessibility to Developers
- Debian packaging + cli interface + pristine-root + automated testing
- code: see the 'integration' branches of rainbow and nss-rainbow and the 'master' branch of test-rainbow
- P_NETWORK
- See Isolation LSM, http://lkml.org/lkml/2009/1/7/18, http://lkml.org/lkml/2009/1/7/613, and http://lxc.sourceforge.net.
- P_DOCUMENT*
- See Olpcfs and Journal reloaded, other thoughts welcome.
- P_X
- -- we'll start by trying out XSECURITY (i.e. by making activities untrusted clients) and see where that leaves us. Then on to XACE as per previous discussion
- -- unfortunately, it seems (c.f. ssh man page) that most apps break when you treat them as untrusted clients. Hmm.
Demo Ideas
- (paraphrase): "The insight behind Rainbow is that the problem of isolating an operator from his/her programs is similar to the problem of isolating users of a shared server from one another and from root." -- C. Scott Ananian
- "I see the cool parts [of Rainbow] as (1) per-instance isolation, (2) isolation without virtualization, and (3) isolation using the uid mechanisms. All three are unique and impressive." -- Ben Schwartz
- (NB: Actually, lots of other people have played with these ideas. plash is a compelling example.)
Ideas:
- Give people an isolated Terminal to play in.
- Show off rlimits with a fork-bomb.
- Show off filesystem protections -- rm -rf, restriction of readable dirs, etc.
Items of Historical Interest
- README - A description of the original scope and design of Rainbow.
- Notes - Notes on design and hurdles in developing Rainbow.
- Rainbow/DataStore Access - thoughts on datastore access mechanisms, superseded by Olpcfs.
- "Why not SELinux?"
- "Bitfrost Compliance for Update.1" announcement mail
- #2732, #2906, #4184 - influential tickets in the history of rainbow