Rainbow: Difference between revisions

From OLPC
Jump to navigation Jump to search
mNo edit summary
m (Reverted edits by 77.64.72.243 (Talk) to last revision by FGrose)
 
(23 intermediate revisions by 3 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.*'''
== Further Information ==


* [[Rainbow/Current Situation|current situation]]: feature, design, and implementation notes for rainbow-0.8.*
* Information for [[Rainbow/Information for Activity Developers|Activity Developers]]
* [[Rainbow/Installation Instructions|installation instructions]] for rainbow-0.8.*
* Information about Rainbow's [[Rainbow/Current Design and Implementation|current design and implementation]].
* [[Rainbow/Testing|testing]] instructions for rainbow-0.8.*
* Information about [[Rainbow/Historical Designs|older designs]]
* [[Rainbow/Installation Instructions|installation instructions]]
* [[Rainbow/Next Steps|next steps!]]
* [[Rainbow/Testing]]
* [[Rainbow/Demo Ideas|demo ideas]]
* [[Rainbow/Next Steps]]
* [[Rainbow/Curiosities]]


'''Other Information'''
== Next Steps ==
Last updated: [[User:Mstone|Michael Stone]] 21:59, 16 May 2009 (UTC)


* notes for [[Rainbow/Information for Activity Developers|Activity Developers]], for Sugar 0.82 and rainbow-0.7.*
; Job control features
* [[Rainbow/Historical Designs|historical design comparisons]], for rainbow-0.6.*, -0.7.*, and -0.8.*
: 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.
* [[Rainbow/Curiosities|curiosities]]

==Subpages==
; D-Bus changes for sugar activities
(Titles in ''italics'' redirect to another page.){{Special:PrefixIndex/{{PAGENAME}}/}}
: 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].

; sugar-jhbuild integration
: Sugar folks have [http://lists.sugarlabs.org/archive/sugar-devel/2009-February/012188.html asked] for jhbuild integration to ease testing. Maybe some kind soul will donate it?

; 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/security/tree/rainbow/README README] - A description of the original scope and design of Rainbow.
* [http://dev.laptop.org/git/security/tree/rainbow/NOTES 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]  +/-  

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