Rainbow/Current Situation: Difference between revisions

From OLPC
Jump to navigation Jump to search
mNo edit summary
 
(26 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{Rainbow page}}
{{Rainbow page}}


=== Features ===


The main features implemented by the current design are:
[[Rainbow]] has been implemented according to [[Rainbow/Historical Designs|three designs]] to date. The present design, implemented in the "rainbow-0.8.*" series, works like this:


* process isolation
rainbow-0.8.* isolates programs ([http://en.wikipedia.org/wiki/Process_(computing) processes]) by confining them to accounts with access control [http://linux.die.net/man/7/credentials credentials] which limit the confined programs' ability to commit side-effects like filesystem I/O.
* filesystem isolation
* optional primitive video/audio hardware isolation
* optional experimental X11 isolation


=== Design ===
In particular, rainbow-0.8.* provides isolation by means of [http://en.wikipedia.org/wiki/File_system_permissions traditional Unix permissions]. It creates the accounts used for this task by means of an [http://www.gnu.org/s/libc/manual/html_node/Name-Service-Switch.html NSS] [http://dev.laptop.org/git/users/mstone/security/tree/rainbow/nss/nss-rainbow.c module] which modifies the appropriate [http://www.gnu.org/s/libc/manual/html_node/Users-and-Groups.html system databases].


Rainbow has been implemented according to [[Rainbow/Historical Designs|three designs]] to date.
rainbow-0.8.* is used via the [http://dev.laptop.org/git/users/mstone/security/tree/rainbow/bin/rainbow-run rainbow-run] [http://en.wikipedia.org/wiki/Chain_loading "exec-wrapper"] or some higher-level tool based on that program such as the [http://dev.laptop.org/git/users/mstone/security/tree/rainbow/bin/rainbow-easy rainbow-easy] convenience wrapper. Either way, the <tt>rainbow-run</tt> wrapper eventually receives control from a higher-level shell, performs any requested [http://dev.laptop.org/git/users/mstone/security/tree/rainbow/rainbow/inject.py isolation steps], and 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.

The present design, implemented in the "rainbow-0.8.*" series, works to isolate [http://en.wikipedia.org/wiki/Process_(computing) processes] by confining them to accounts with access control [http://linux.die.net/man/7/credentials credentials] which limit the confined programs' ability to commit side-effects like [http://www.tldp.org/LDP/khg/HyperNews/get/fs/vfstour.html filesystem I/O].

Structurally, the design consists of:

# a "UI" layer, containing:
#* the [http://dev.laptop.org/git/users/mstone/security/tree/rainbow/bin/rainbow-run rainbow-run] [http://en.wikipedia.org/wiki/Chain_loading "exec-wrapper"] and
#* some higher-level tools based on that program such as the [http://dev.laptop.org/git/users/mstone/security/tree/rainbow/bin/rainbow-easy rainbow-easy] convenience wrapper.
# an [http://dev.laptop.org/git/users/mstone/security/tree/rainbow/rainbow/inject.py injection library], which contains Rainbow's isolation logic
# an [http://www.gnu.org/s/libc/manual/html_node/Name-Service-Switch.html NSS] [http://dev.laptop.org/git/users/mstone/security/tree/rainbow/nss/nss-rainbow.c module].

These components have the following responsibilities:

# The UI is responsible for figuring out what to do and for handing that information to a separate [http://dev.laptop.org/git/users/mstone/security/tree/rainbow/rainbow/inject.py injection library].
# The injection is responsible for:
#* acting on isolation requests by manipulating persistent state held in a filesystem spool,
#* dropping privilege, and
#* handing control to the program being isolated.
# Finally, the rainbow NSS module lets other programs read the rainbow spool through the usual POSIX APIs for reading [http://www.gnu.org/s/libc/manual/html_node/Users-and-Groups.html system databases].

This structure was chosen to so that 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 and so that changes to rainbow can operate without munging important system files like <tt>/etc/passwd</tt> and <tt>/etc/group</tt>.

=== Implementation ===

Here are some key ideas underlying the current implementation:

# "Owners" are the accounts on behalf of which we are isolating a program. They need access to data produced by that program and to space ("topic dirs" and "data groups") through which to share information with it.
# Some times, people will want to re-use a container. Other times, they'll want a fresh one. Containers, being accounts, are identified by uid.
# Control flow is linear within controlling functions like <tt>main()</tt> and <tt>inject()</tt>.
#* Exceptions are used to terminate control flow and to record information about the program's situation when it terminates.
#* Input validation is performed by functions named <tt>check_'''foo'''()</tt>
# State is maintained in a simple filesystem-embedded microformat.
#* Reservations are recorded in <tt>'''foo'''_pool</tt>
#* Maps are named <tt>'''foo'''_to_'''bar'''</tt>
#* Key-value pairs are entries are symlinks from <tt>'''key'''->'''value'''</tt>.
#* SQLite would probably have worked just as well, except that its algorithms are not lock-free.
# We provide isolation by generating low-privilege accounts through the NSS module, then by calling things like
#* <tt>chown()</tt>
#* <tt>chmod()</tt>
#* <tt>setrlimit()</tt>
#* <tt>setgroups()</tt>
#* <tt>setgid()</tt>
#* <tt>setuid()</tt>
# Task-specific "assistant" program like [http://dev.laptop.org/git/users/mstone/security/tree/rainbow/bin/rainbow-xify rainbow-xify] or [http://dev.laptop.org/git/users/mstone/security/tree/rainbow/bin/rainbow-sugarize rainbow-sugarize] provide isolated software with access to task-specific shared resources like:
#* D-Bus sockets,
#* D-Bus cookies,
#* X sockets,
#* X cookies, and
#* temporary filesystems
# Mounting filesystems needs to be done as root and is presently done in a new filesystem namespace (see <tt>CLONE_NEWNS</tt>) in order to reduce resource leakage.

=== Other Notes ===

See [[User:Mstone/Tricks]] for more detail on some of the idioms used rainbow.

Latest revision as of 21:45, 12 June 2009

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


Features

The main features implemented by the current design are:

  • process isolation
  • filesystem isolation
  • optional primitive video/audio hardware isolation
  • optional experimental X11 isolation

Design

Rainbow has been implemented according to three designs to date.

The present design, implemented in the "rainbow-0.8.*" series, works to isolate processes by confining them to accounts with access control credentials which limit the confined programs' ability to commit side-effects like filesystem I/O.

Structurally, the design consists of:

  1. a "UI" layer, containing:
  2. an injection library, which contains Rainbow's isolation logic
  3. an NSS module.

These components have the following responsibilities:

  1. The UI is responsible for figuring out what to do and for handing that information to a separate injection library.
  2. The injection is responsible for:
    • acting on isolation requests by manipulating persistent state held in a filesystem spool,
    • dropping privilege, and
    • handing control to the program being isolated.
  3. Finally, the rainbow NSS module lets other programs read the rainbow spool through the usual POSIX APIs for reading system databases.

This structure was chosen to so that rainbow can be used from freedesktop.org .desktop launcher files, from the command-line, and from custom graphical shells like Sugar with equal ease and so that changes to rainbow can operate without munging important system files like /etc/passwd and /etc/group.

Implementation

Here are some key ideas underlying the current implementation:

  1. "Owners" are the accounts on behalf of which we are isolating a program. They need access to data produced by that program and to space ("topic dirs" and "data groups") through which to share information with it.
  2. Some times, people will want to re-use a container. Other times, they'll want a fresh one. Containers, being accounts, are identified by uid.
  3. Control flow is linear within controlling functions like main() and inject().
    • Exceptions are used to terminate control flow and to record information about the program's situation when it terminates.
    • Input validation is performed by functions named check_foo()
  4. State is maintained in a simple filesystem-embedded microformat.
    • Reservations are recorded in foo_pool
    • Maps are named foo_to_bar
    • Key-value pairs are entries are symlinks from key->value.
    • SQLite would probably have worked just as well, except that its algorithms are not lock-free.
  5. We provide isolation by generating low-privilege accounts through the NSS module, then by calling things like
    • chown()
    • chmod()
    • setrlimit()
    • setgroups()
    • setgid()
    • setuid()
  6. Task-specific "assistant" program like rainbow-xify or rainbow-sugarize provide isolated software with access to task-specific shared resources like:
    • D-Bus sockets,
    • D-Bus cookies,
    • X sockets,
    • X cookies, and
    • temporary filesystems
  7. Mounting filesystems needs to be done as root and is presently done in a new filesystem namespace (see CLONE_NEWNS) in order to reduce resource leakage.

Other Notes

See User:Mstone/Tricks for more detail on some of the idioms used rainbow.