setup for XO development

[Michael Stone]

On Thu, Oct 30, 2008 at 04:35:30PM -0500, David Farning wrote:
>On Thu, Oct 30, 2008 at 4:18 PM, Michael Stone <michael at laptop.org> wrote:
>> Actually, for a variety of reasons, I'm working quite hard to make
>> rainbow usable on stock linux machines like those represented by
>> Debian and Fedora chroots.
>>
>
>Michael,
>Could you provide a high level comment on the feasibility of running rainbow
>as a security mechanism on Sugar on Fedora of Debian machines without the
>chroot?

Feasible, but it would go faster with some help. (The chroots are just
for convenience so I can test both platforms in a repeatable fashion on
a single machine.)

In more detail: 

  * I've got a new version of rainbow in the works which sits as an
    exec-wrapper around any program you want to run. I've also got
    tentative sugar patches for making sugar use this rainbow.

  * When invoked, rainbow generates new credentials (e.g. uid, gid) if
    necessary, assumes its new identity, sets any requested rlimits,
    closes filedescriptors, and hands over control to the program of your
    choice.

     * The user and group manipulation is accomplished by manipulating
       some files in a spool directory at the location of your choice; a
       separate glibc NSS module reads this information and returns it
       through the standard libc apis on demand. 
       
  * Human operators assume the authority necessary to perform this
    operation by means of a setuid helper, e.g. sudo. 

This design makes it eminently feasible to port to any glibc-based Unix
platform and, with a bit more care, to any POSIX platform on which we
know how to make new users and groups and are permitted to assume their
identity.

Caveats: 

   a) the implementation is not yet capable of isolating multiple human
   operators from one another, though I expect to implement this
   functionality in the not-too-distant-future.

   b) the implementation provides nothing more and nothing less than the
   isolation provided by running programs under fresh uids and gids. Many
   sorts of mischief are still possible, particularly on systems which
   set lax default permissions on user home directories (e.g. Debian).

   c) the implementation is quite new and is hence highly likely to
   contain bugs, unstable APIs, etc.

   d) rainbow is still written in fairly naive python and it pays the
   usual speed and memory price for this convenience. (It also uses at
   least one naive algorithm when selecting new credentials.)

   e) I have removed support for the rainbow dbus daemon since it was
   needlessly complicating my life. It remains to be seen whether
   activities' startup procedures can be sped up enough to sustain this
   change.

For these reasons, the new implementation is still far from 'production
quality'; however, that's no reason not to start trying it out. (Code is
available in the 'integration' branch in the users/mstone/security and
users/mstone/nss-rainbow repos on dev.laptop.org.)

Regards,

Michael