[OLPC Security] Rainbow interactions with Activity processes, rate limiting specs

[Adric Net]

Hi,

Thanks for correcting me  and some clarification, and many thanks for  
bringing us back on topic. :)
And the rest is inline...

On Nov 30, 2007, at 1:24 AM, Michael Stone wrote:

> Specifically, it's fairly clear from the needs of software like Browse
> and Etoys that 'activity instances' are not in one-to-one  
> correspondence
> with processes or even process-groups. This means that you may not  
> know
> which uid to kill off in order to close a given activity instance and
> that one uid may be hosting several unrelated activities.
>

Hmm, I'm not entirely sure I follow you here... If you could sketch  
out an
activity instance, please, so that I (we) see the bigger picture than  
the processes?
Or is there wiki on that already that I missed?

> [snip]
>
> All of these kinds of communication create unknown levels of risk of
> cross-instance contamination. The ones involving the datastore may
> persist across reboots. Finally, each suggests the possibility of
> running privilege-escalation attacks against system and session
> components that I am hard-pressed to mitigate on any reasonable
> timeframe.

Okay, now that I understand. And we have a lot of executable code/ 
content
that we want them to share cross-Activity and even across the mesh.  
This is
going to be a vector.

> To come to Marcus' defense here, he's one of the people who has
> contributed most directly to implementing Bitfrost by code review,  
> patch
> submission, and regular testing to ensure that the code continues to  
> run
> under emulation.
>

Awesome!

> Depends on whether you're able to specify workable limits and on the
> rate at which exploits are developed for the activities that are  
> endowed
> with network access. (or for the underlying system as a whole).

And this is something still under development and scrutiny. We (I)  
should probably start testing
this (on closed networks, at first) to see how bad things are in the  
current builds.  I know that
this stuff has limited implementation so far ? eg /etc/rainbow ?

>
> Here's a potential weakness that concerns me: how rapidly can we
> actually deploy a security patch to, say, avahi or the presence  
> service?
>

This is a major concern, and one that may be out of spec because of  
the distribution methods.
To my understanding once the XOs go out, laptop.org may never hear  
from them again, in many
non-edge cases. Of course the sponsoring government and classrooms  
will be encouraged to
distribute patches to all of their XOs, but ... *gulp*

When if ever are y'all on IRC? :)

Thanks,
Adric Net