setup for XO development

[Bobby Powers]

On Fri, Oct 31, 2008 at 12:12 AM, Michael Stone <michael at laptop.org> wrote:
> 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.)

very interesting.  you mentioned working to integrate rainbow with
sugar-jhbuid.  It seems like that should be using this native version.
  If we're not using the d-bus daemon, would we then have to start
jhbuild with 'sudo'?  Do you have any further pointers on what to look
out for when trying to integrate it into jhbuild?

yours,
Bobby