Rainbow

  This page is monitored by the OLPC team.

  For Developers

english | español

HowTo [ID# 197142]  +/-

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

git :: sources :: rainbow-0.8.2.tar.bz2

The Bitfrost security specification argues that existing desktop security conventions do not meet the security needs of adventurous kids in 1-1 computing programs, of the technical staff who help maintain such initiatives, and of the political constituencies which determine where such programs take place. The most serious inadequacy of such systems is that they force end-users to take unnecessary security risks (for example, giving all programs a user runs access to the network, to auto-start facilities, and to other programs' data files) while simultaneously denying users the opportunity to do things which can be done safely but which were not anticipated by the system administrator (notably, installing new software or modifying the local system.) Consequently, we wrote Rainbow.

Rainbow is an isolation shell. This means two things:

1. shell: Rainbow runs programs on behalf of humans and programs. Rainbow provides those programs with a suitable environment: places in which temporary and persistent data can be stored, environment variables to identify those places, etc.
2. isolation: People and programs should use Rainbow when they want to isolate programs from other programs and important system resources. "Isolation" is already a familiar concept to most UNIX programmers: many system daemons already operate using their own unique UID and/or GID, and most have private places in which they store their configuration. Rainbow generalizes and extends this paradigm by providing every program it runs with a unique identity, with private storage, with pre-configured resource usage limits, etc.

At the moment, Rainbow only knows how to provide the same primitive form of filesystem and signal isolation that competent sysadmins provide to users of multi-user Unix shell servers.

However, contributions are welcome, particularly contributions which advance existing plans.

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).

In general, developers that are creating activities from scratch will be less frustrated by Rainbow's restrictions than those attempting to port existing activities into this environment. User-oriented programs traditionally haven't had restrictions on where their data can be stored, what kinds of actions they can perform. A program that assumes it can save private configuration or state under $HOME/.myprogrc, for instance, will need to be modified: under Rainbow the program runs as a different UID, and writing to the invoker's $HOME will fail. Other traditional filesystem references may fail as well. Again, these restrictions are described in the low-level activity api documentation.

Disabling Rainbow for Testing

Sugar's use of 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.

Responding to Isolation

The Low-level Activity API's security section explains some basic ways that activities should respond to being isolated, particularly with regard to isolation from the file system.

Customizing Isolation

The Activity bundles' activity/permissions.info documentation offer some hints on how activities may currently customize the isolation provided by rainbow.

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.

Installation

Last updated: Michael Stone 21:36, 27 February 2009 (UTC)

0.8-series

The basic idea is to install rainbow, either

from a distro package:

• Fedora >= 10: yum install rainbow
• Ubuntu: Bernie's PPA contains some basic rainbow packages which you can install.
• Other: Install rainbow from source or help others by packaging it for your distro!

from source:

RAINBOW=rainbow-0.8.2
wget http://dev.laptop.org/~mstone/releases/SOURCES/$RAINBOW.tar.bz2
tar xf $RAINBOW.tar.bz2 && cd $RAINBOW
make -f Makefile.build build
sudo make -f Makefile.build install

from a unified builder or image:

like sugar-jhbuild or Sugar on a Stick (SoaS). (nb: future work)

setup:

In order for rainbow to function, you need to inject its users and groups into the system by running:

sudo /bin/sed -i -e s/^passwd:/passwd:\ rainbow/ /etc/nsswitch.conf
sudo /bin/sed -i -e s/^group:/group:\ rainbow/ /etc/nsswitch.conf

Currently, you also need to change the D-Bus configuration to allow users besides the owner to access the session bus. This might allow others on the same machine to control your applications and access your data, so only do this change if you're fine with that (e.g. no one else or only trusted ones using your computer). You need to add the following line to /etc/dbus-1/session.conf inside the <policy context="default"> section:

   <allow user="*"/>

Congratulations. You are now ready to test rainbow.

Testing

Rainbow is easy to test in chroots, for example, those created by mock. See test-rainbow and, in particular,this small multi-user test script.

To test it on a regular system, you might install it, then run something like:

 sudo rainbow-run -q -s /var/spool/rainbow/2 -c / -f 0 -f 1 -f 2 -u `whoami` -i nice -- /bin/bash

This will drop you into an isolated bash session in which you can play.

NB: If you want to isolate graphical software, then you're going to need to use a helper program like rainbow-sugarize to provide an X cookie, access to the D-Bus session bus, etc.

Obviously, please contribute more automated tests, helpers, and bug reports!

Next Steps

Last updated: Michael Stone 17:48, 1 March 2009 (UTC)

Integration with sugar-0.86

There are a couple of small impedance mismatches that will need to be overcome; e.g. sugar needs a way to kill an activity, a way to garbage-collect dead jails, and a way to reuse a jail when an activity is to be resumed.

We also need to find a way to make dbus session buses happy accepting connections from per-bus groups of users. The current plan is to implement a "group_pattern" authorization attribute and to have libnss_rainbow synthesize the appropriate group memberships. We'll start with positive and negative automated tests.

Ben Schwartz points out that this functionality could also be hacked together with the regular allow-group authorization element if only dbus session buses sourced per-user configuration.

P_NETWORK

We'd like to have the option to restrict a program's access to the network. James Morris suggests that we check out unshare(CLONE_NEWNET).

See Isolation LSM, http://lkml.org/lkml/2009/1/7/18, and http://lkml.org/lkml/2009/1/7/613 for some other approaches.

P_DOCUMENT*

Requested by Gary C. Martin. To implement this, we need to put some authorization gates in the datastore, then somehow record which data should be accessible to which activities. (Or maybe we could do it all with ACLs?)

See Olpcfs and Journal reloaded for some other approaches.

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