[Sugar-devel] Future of Rainbow + Sugar?

[John Gilmore]

>                                  The userland application privilege
> isolation is hugely important, as we are pushing for making our apps
> heavily network oriented, the risks of other network hosts trying to
> take advantage of vulnerable apps is huge.

A problem with expanding Rainbow to other desktops is that the
Rainbow model derives from the Sugar model, which is that only
custom-written and therefore "Sugarized" programs run in the Rainbow
environment.  In other words, Sugar and Rainbow draw a hard line in
the sand between "Sugar Activities" and ordinary programs.  Rainbow
protects Sugar Activities, but doesn't affect ordinary programs.

Most other systems don't have that hard line.  The shell, the
compilers, the clock in the corner of your screen, the browser, are
all just programs.  They all run with the same privileges and can
access the same files and networks.  You can just run them anytime,
from any shell or script.  They don't have to go through a dbus
interface, interact with the user, and be passed a file descriptor to
read a file; they can and do just call open() or fopen().  This
straightforwardness and POSIX compatability doesn't work under
Rainbow.  This is why so many programs needed to be patched to run
under Rainbow -- and why the maintainers of those programs weren't
interested in incorporating Rainbow-specific patches.

If Rainbow was optional, that would be different.  Programs that
*want* to run with higher security and less functionality could use
it.  Most wouldn't even lose any functionality, because Rainbow would
only be eliminating options that the programs never use.  That was its
design goal -- to eliminate capabilities that a program was never
designed to use, so the program can't be subverted by an attacker to
exploit those capabilities.  Its early implementation became more of a
straitjacket than a benign helper, with programs failing to run when
Rainbow was "turned on" globally.

It's a hard job to design and implement a good generic "capabilities"
system for a POSIX environment.  So far nobody has done it (including
Rainbow).  The basic ideas of "mark programs with the capabilities
they need (or don't need), and have exec() disable the ones the
program doesn't need", and "have programs drop excess capabilities
after initializing" are good ones.  The devil is in the details.  The
kernel part is relatively simple.  It's a harder job to enable
capabilities that are far beyond the kernel's ability to police, like
"disable this program's ability to listen to a built-in microphone";
that requires security-sensitive changes to a whole variety of
libraries, software, and controls.

	John