[OLPC Security] Bitfrost vs. Rainbow

[Mark Seaborn]

Michael Stone <michael at laptop.org> wrote:

> > However, a quick look at relevant Rainbow docs (specifically [2])
> > indicate that Rainbow might be implemented using only the standard Linux
> > DAC mechanisms -- essentially, very similar to the Polaris design[3].
> 
> Correct to date, though we've basically reached the limits of the
> existing DAC framework. Clever (or stupid, depending on your
> perspective) hacks now seem to be required. For network isolation, I'm
> currently intending to go forward with compartmentalized "network" and
> "not-network" processes based on Dan Bernstein's sys_disablenetwork()
> idea [2]. 
> 
>   [2]: http://cr.yp.to/unix/disablenetwork.html

That is the approach I would like to take with Plash for limiting
network access.  In general, I would like to be able to disable most
system calls, leaving only those that deal purely with file
descriptors (as listed on http://plash.beasts.org/wiki/PtraceJail).
One way to do that would be to use ptrace(), possibly with Jeff Dike's
PTRACE_SYSCALL_MASK patch.


> For X, I'm still at the research stage, currently investigating both
> XACE [3] and an off-the-cuff idea involving per-uid Xephyrs (or
> similar tomfoolery).

I have been investigating this area and there are some notes on the
Plash wiki:
http://plash.beasts.org/wiki/X11Security
http://plash.beasts.org/wiki/X11SecurityRequirements

I expect that Sugar's X security requirements would be easier to meet
than mine, since Sugar's GUI is much simpler, lacking a conventional
window manager with overlapping windows.

What are you considering doing with Xephyr?

I have considered adapting Xnest to support a rootless mode (similar
to Cygwin X's rootless mode) in which Xnest's top-level windows
co-exist among the parent X server's top-level windows, instead of
appearing inside a nested window.  It did not appear to be practical
because Xnest re-uses all of a normal X server's keyboard and mouse
input processing, including grab processing.

I have investigated XACE and decided against using it for reasons that
are partly architectural and partly practical.  The idea of filtering
X requests does not fit with Plash's aim of having a capability
architecture.  Since XACE is just a set of internal server hooks, it
requires a lot to be done on the server side.  I am not convinced that
my requirements for handling top-level windows and proxying access to
the X clipboard can be achieved using something like XACE without
putting a lot of complexity into the X server.

I have been experimenting with writing a security-enforcing X proxy.
I've got an incomplete prototype written in Python:
http://plash.beasts.org/wiki/X11ProxySpike


> P.S. - It sounds like our goals are closely aligned with some of the
> goals of the Plash project - also, OLPC has no desire to maintain
> bespoke security software just for kicks. Can you suggest some an
> approachable Plash developer (or mailing list?) to suggest that we
> explore ways to further our mutual aims in concert?

I'm the main Plash developer.  I read this list but you're welcome to
post on Plash's mailing list
(http://lists.nongnu.org/mailman/listinfo/plash) or cross-post.

I've been on this list since Bitfrost was announced.  It's good to
hear some more details about the planned implementation.  I don't
think I knew before today that the implementation is called Rainbow!

Regards,
Mark