Rainbow: Difference between revisions

From OLPC
Jump to navigation Jump to search
mNo edit summary
mNo edit summary
Line 13: Line 13:
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]].


== Further Information ==
'''Further Information'''


* for [[Rainbow/Information for Activity Developers|Activity Developers]]
* for [[Rainbow/Information for Activity Developers|Activity Developers]]
Line 26: Line 26:
* [[Rainbow/Curiosities|curiosities]]
* [[Rainbow/Curiosities|curiosities]]


== 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 ==
== Items of Historical Interest ==

Revision as of 19:46, 12 June 2009

  english | español HowTo [ID# 210027]  +/-  

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

Further Information


Items of Historical Interest