[OLPC Security] Bitfrost vs. Rainbow

[Michael Stone]

Mark,

First, thanks very much for your commentary; I apologize that I was
unable to reply until now.

On Tue, Apr 01, 2008 at 07:50:52PM +0100, Mark Seaborn wrote:
> Michael Stone <michael at laptop.org> wrote:
> 
> >   [2]: http://cr.yp.to/unix/disablenetwork.html
> 
> That is the approach I would like to take with Plash for limiting
> network access.  

I took a fairly direct route toward this goal: namely, I wrote a
'long sys_disablenetwork(void)' syscall and an LSM to implement it [1].
(I chose to use an LSM because OLPC is not presently using any LSMs and
because it requires no changes to the kernel's task_struct.) 

[1]: http://dev.laptop.org/git?p=users/mstone/olpc-2.6;a=commit;h=c05cc7eadcee3d9450c1eb6a41ef9c932f9aad53

I have not yet made any attempts to push this work into use, largely due
to my unfamiliarity with the overall kernel development process and the
limited time that I'm able to devote to the problem.

> > 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.

I had a nice chat with an X developer last night (Ajax) about our
security goals. We reached the tentative conclusion that event synthesis
and input injection attacks are much more problematic for OLPC than are
snooping attacks. At this point, my goals are to

  1) make sure Xtest is disabled.
  2) examine and control XSendEvent().
  3) disable or rate-limit changes to the keyboard map in order to
     prevent keypress spoofing attacks against the user.
  4) keep reading until I understand the DnD and clipboard protocols
     clearly enough to evaluate them.

> What are you considering doing with Xephyr?

Basically, I was curious whether we could provide separate X servers for
each activity and then fix up DnD and the clipboard afterward. I asked Jim
Gettys to think about it and he replied that he presently thinks it will
be easier to write an appropriate XACE module. (DnD, clipboard, hardware
acceleration, and the Input layer were the major concerns.)

> 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.

Could you say more about your goals for the clipboard?

Thanks,

Michael