Rainbow: Difference between revisions

From OLPC
Jump to navigation Jump to search
m (Reverted edits by 77.64.72.243 (Talk) to last revision by FGrose)
 
(36 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{translations}}
{{translations}}
<noinclude>{{Google Translations}}
<noinclude>{{ GoogleTrans-en | es =show | bg =show | zh-CN =show | zh-TW =show | hr =show | cs =show | da =show | nl =show | fi =show | fr =show | de =show | el =show | hi =show | it =show | ja =show | ko =show | no =show | pl =show | pt =show | ro =show | ru =show | sv =show }}</noinclude>{{TOCright}}
[[Category:Security]]
== Introduction ==
</noinclude>{{Rainbow page}}
''[http://dev.laptop.org/git/users/mstone/security git] :: [http://dev.laptop.org/~mstone/releases/SOURCES sources] :: [http://dev.laptop.org/~mstone/releases/SOURCES/rainbow-0.8.4.tar.bz2 rainbow-0.8.4.tar.bz2] :: [http://lists.sugarlabs.org/archive/sugar-devel/2009-April/013732.html announcement]''


The [[OLPC Bitfrost|Bitfrost]] security specification argues that existing desktop security conventions do not meet the security needs:
The [[OLPC Bitfrost|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, [[Security credits#Activity Isolation|we]] wrote Rainbow.
* 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, [[Security credits#Activity Isolation|we]] wrote [http://dev.laptop.org/git/users/mstone/security/tree/rainbow Rainbow].


Rainbow is an isolation shell. This means two things:
Rainbow is an isolation shell. This means two things:
Line 13: Line 19:
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.
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, '''[[Security#Contributions|contributions]]''' are welcome, particularly contributions which advance [[#Next Steps|existing plans]].
However, '''[[Security#Contributions|contributions]]''' are welcome, particularly contributions which advance [[Rainbow/Next Steps|existing plans]].


'''Information about rainbow-0.8.*'''
== For Activity Developers ==


* [[Rainbow/Current Situation|current situation]]: feature, design, and implementation notes for rainbow-0.8.*
Though Rainbow is general-purpose software, it is most frequently encountered in the context of Sugar in that when a human asks Sugar to start an activity, Rainbow is usually the software which actually asks the Linux kernel to do the 'starting'. You can find out more about the restrictions Rainbow places on software that it runs in this context in the [[Low-level Activity API#Security|low-level activity api]] documentation, in the [[Sugar almanac]], or below.
* [[Rainbow/Installation Instructions|installation instructions]] for rainbow-0.8.*
* [[Rainbow/Testing|testing]] instructions for rainbow-0.8.*
* [[Rainbow/Next Steps|next steps!]]
* [[Rainbow/Demo Ideas|demo ideas]]


'''Other Information'''
=== Filesystem Isolation ===


* notes for [[Rainbow/Information for Activity Developers|Activity Developers]], for Sugar 0.82 and rainbow-0.7.*
Suppose program A (e.g. sugar) uses rainbow-0.7.x to isolate program B (e.g. your activity).
* [[Rainbow/Historical Designs|historical design comparisons]], for rainbow-0.6.*, -0.7.*, and -0.8.*

* [[Rainbow/Curiosities|curiosities]]
# Rainbow's isolation means that program A's $HOME and program B's $HOME will be different directories and that, in general, program B will have no authority write (or perhaps, to read) files contained in program A's $HOME.
==Subpages==
# Programs isolated by early versions of rainbow-0.7.x are only permitted to write to three subdirectories of their $HOME directories. You can read the [[Low-level Activity API#Security|low-level activity api]] for the gory details; the summary is that if your software needs to be portable over XO software releases 7.1-8.2 (e.g. builds 650, 656, 703, 767), then you are only guaranteed the ability to write to $SUGAR_ACTIVITY_ROOT/{data,tmp,instance}. Note: "$SUGAR_ACTIVITY_ROOT" is commonly abbreviated as "$SAR" in conversations and in this text.
(Titles in ''italics'' redirect to another page.){{Special:PrefixIndex/{{PAGENAME}}/}}
# Rainbow-0.7.x guarantees that only $SAR/data will be available the next time your activity is launched. The other two directories will be wiped clean at various convenient times in the future.
# Persistent data saved in $SAR/data MUST be group-readable and writable so that new instances of your activity can continue to manipulate it. Rainbow tries to make this easy for you by setting umask(000) but there are some libraries (particularly those provided by Mozilla) which hard-code the use of inappropriate file modes.

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

=== Customizing Isolation ===

The [[Activity bundles#activity/permissions.info|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 [http://en.wikipedia.org/wiki/Chain_loading "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 [http://freedesktop.org freedesktop.org] [http://standards.freedesktop.org/desktop-entry-spec/latest/ .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 [http://www.freedesktop.org/wiki/Software/dbus dbus] [http://en.wikipedia.org/wiki/Daemon_(computer_software) 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 [http://linux-vserver.org 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. [[User:Mstone|Michael Stone]] created a new design outline, written up in [http://dev.laptop.org/git/security/tree/rainbow.txt 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 [http://en.wikipedia.org/wiki/File_system_permissions 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 [http://en.wikipedia.org/wiki/Chroot chroots], [http://lwn.net/Articles/159077/ bind-mounts] (including read-only bind-mounts), and [http://linux-vserver.org/Paper#Filesystem_XID_Tagging 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 [http://linux-vserver.org/CPU_Scheduler 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 [[#Next Steps|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 [http://linux-vserver.org/Paper#Network_Separation network separation] features.

== Installation ==
Last updated: [[User:Mstone|Michael Stone]] 21:07, 9 March 2009 (UTC)

The basic idea is to install rainbow, either

'''from source:'''

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

'''from a distro package:'''

* Fedora >= 10: yum install rainbow
* Ubuntu: [https://launchpad.net/~codewiz/+archive/ppa 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 a unified builder or image:'''

like [http://sugarlabs.org/go/DevelopmentTeam/Jhbuild sugar-jhbuild] or [http://sugarlabs.org/go/Sugar_on_a_Stick 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

To use the current "rainbow-easy" helper, you need to have an "audio" group on your system:

sudo groupadd -f audio

To use Rainbow with Sugar Activities, you need to add the following line to /etc/dbus-1/session.conf inside the <policy context="default"> section:

<allow user="*"/>

This will allow other uids besides yours to access the session bus. This might allow people on the same machine to control your applications and access your data, so only make this change if you're
fine with that (e.g. no one else or only trusted ones using your computer). (We hope to improve on this situation in the future.)

Congratulations. You are now ready to test rainbow.

== Testing ==

Rainbow is easy to test in chroots, for example, those created by [http://fedoraproject.org/wiki/Projects/Mock mock]. See [http://dev.laptop.org/git/users/mstone/test-rainbow test-rainbow] and, in particular,this [http://dev.laptop.org/git?p=users/mstone/test-rainbow;a=blob;f=suggestions;hb=HEAD small multi-user test script].

To test it on a regular system, you might [[#Installation|install it]], then run something like:

sudo rainbow-easy gaming /bin/bash
sudo rainbow-easy banking /usr/bin/firefox -no-remote
sudo rainbow-easy av /usr/bin/mplayer ~/some/movie

These examples will drop you into an isolated bash session, firefox session, or mplayer session in which you can play.

''NB: If you want to isolate more complicated software, then you're going to use the low-level <tt>rainbow-run</tt> interface used by <tt>rainbow-easy</tt>. Here are some examples to help you get started:

''Launch mplayer with a fresh nested Xephyr X server.''
sudo rainbow-run -v -v -v -s /var/spool/rainbow/2 -u $USER -c "`pwd`" -f 0 -f 1 -f 2 -E "DISPLAY=:0" -o audio -a /usr/bin/rainbow-xify -o xephyr -- /usr/bin/mplayer ~/some/movie
''Launch bash in a previously generated container.''
sudo rainbow-run -v -v -v -s /var/spool/rainbow/2 -u $USER -f 0 -f 1 -f 2 -i secrets -r 10000 -- /bin/bash
Obviously, please contribute more automated tests, helpers, and [[Reporting bugs|bug reports]]!

== Next Steps ==
Last updated: [[Special:Contributions/24.91.152.118|24.91.152.118]] 21:59, 16 May 2009 (UTC)

; Job control features
: 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.

; D-Bus changes for sugar activities
: We 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 [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%23480223 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 [http://lxc.sourceforge.net 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]], [[Journal reloaded]], [[Olpcfs2]], and [[Journal and Overlays]] for some other approaches.

; P_X
: http://dev.laptop.org/git/users/mstone/security/log/?h=xephyr contains very rough patches which cause rainbow to generate Xephyrs in which to isolate some of its clients' X abuse.
:: -- NB: Recent versions of Xephyr (>=1.5.99) are required for OpenGL clients.
:: -- Also, Firefox doesn't yet like Xephyr. Help debugging would be greatly appreciated.
: Future work: try out XSECURITY on the main xserver (i.e. by making activities untrusted clients) and see where that leaves us. Then on to XACE as per [http://lists.laptop.org/pipermail/security/2008-April/000390.html 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. [http://plash.beasts.org/wiki/ 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 ==

* [http://dev.laptop.org/git?p=security;a=blob;f=rainbow/README;hb=HEAD README] - A description of the original scope and design of Rainbow.
* [http://dev.laptop.org/git?p=security;a=blob;f=rainbow/NOTES;hb=HEAD Notes] - Notes on design and hurdles in developing Rainbow.
* [[Rainbow/DataStore Access]] - thoughts on datastore access mechanisms, superseded by [[Olpcfs]].
* [http://lists.laptop.org/pipermail/security/2008-January/000370.html "Why not SELinux?"]
* [http://lists.laptop.org/pipermail/sugar/2007-November/003725.html "Bitfrost Compliance for Update.1" announcement mail]
* {{Ticket|2732}}, {{Ticket|2906}}, {{Ticket|4184}} - influential tickets in the history of rainbow

[[Category:Software]]
[[Category:Security]]

Latest revision as of 21:00, 26 November 2011

  english | español HowTo [ID# 263143]  +/-  
Google translations: Afrikaans العربية azərbaycanca Bahasa Indonesia Bahasa Melayu беларуская বাংলা български català čeština Cymraeg dansk Deutsch eesti Ελληνικά English español Esperanto euskara فارسی français Gaeilge galego ગુજરાતી 한국어 עברית हिन्दी հայերեն hrvatski íslenska italiano ქართული ಕನ್ನಡ Kiswahili Kreyòl ayisyen Latina latviešu lietuvių magyar македонски Malti Nederlands 日本語 norsk polski português română русский shqip slovenčina slovenščina српски / srpski suomi svenska ไทย Tagalog தமிழ் తెలుగు Tiếng Việt Türkçe українська اردو ייִדיש 中文（中国大陆） 中文（臺灣）

Rainbow :: git :: sources :: rainbow-0.8.6.tar.bz2 :: announcement

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.

Information about rainbow-0.8.*

Other Information

Subpages

(Titles in italics redirect to another page.)

Retrieved from "http://wiki.laptop.org/mediawiki/index.php?title=Rainbow&oldid=263143"