Rainbow/Historical Designs
Design
Rainbow has been implemented according to three designs to date.
Overview
0.8-series
The 0.8 series is designed as an "exec-wrapper". The "rainbow-run" wrapper 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 dbus 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.
0.6-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.
Filesystem Isolation
0.7-, 0.8-series
The 0.7- and 0.8-series Rainbow designs provide authorization-based filesystem isolation by means of traditional Unix permissions. We simply make new system accounts on demand and isolate programs by confining them to accounts with limited filesystem access.
(Essentially, programs are permitted to write to /tmp, /var/tmp, and to their home directories. Some early 0.7-series rainbows only permitted writes to /tmp, /var/tmp, and the "data, tmp, and instance" subdirectories of the directory named in the "$SUGAR_ACTIVITY_ROOT" environment variable. Programs may read any world-readable files contained in traversable directories. To date, this includes most user data, though it does not usually include user-owned cryptographic keys.)
0.6-series
The 0.6-series Rainbow design provided both name-based and authorization-based filesystem isolation by means of chroots, bind-mounts (including read-only bind-mounts), and per-file XID tagging.
CPU Isolation
0.7-, 0.8-series
The 0.7- and early 0.8-series Rainbows do not provide any form of CPU resource limiting.
0.6-series
The 0.6-series rainbows provided cpu resource limiting by means of VServer's CPU Scheduler limits.
Network Isolation
0.7-, 0.8-series
The 0.7- and early 0.8-series Rainbows do not provide any form of network isolation. See the P_NETWORK next steps for future plans.
0.6-series
The 0.6-series rainbows provided basic "on/off" network isolation by means of VServer's network separation features.