Rainbow has been implemented according to three designs to date.
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.
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.
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.
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.)
The 0.7- and early 0.8-series Rainbows do not provide any form of CPU resource limiting.
The 0.6-series rainbows provided cpu resource limiting by means of VServer's CPU Scheduler limits.
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.
The 0.6-series rainbows provided basic "on/off" network isolation by means of VServer's network separation features.