[OLPC Security] Please read the spec and the discussion first, thanks. Was: Re: A mom's worries

[Michael Stone]

Adric,

> Since, as you acknowledge earlier, each Activity is started in it's  
> own UID, then it is trivial to make sure that all processes started by  
> that user and all of their children die when the Activity is  
> terminated, eg `slay 1003`. 

It may be 'trivial' to kill all processes started by a given user, but
it's not obvious to me that this solves the problem Marcus raised, for
two reasons, one specific and one general. 

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.

More generally, activity instances can communicate with one another
through four basic mechanisms (and probably a few side-channels).

First, instances of the same activity-type can communicate directly
through their shared 'data' dir.

Second, instances of differing types can communicate, with user consent,
through the datastore and the clipboard, and without user consent
through DBus, through X, and perhaps over the network.

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.

> So, pointing out that 'weakness' is not particularly helpful, but
> submitting a patch that adds that command to activity tear-down might
> be.

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.

> Similarly, discussion of spamming is hopefully mitigated by the  
> default network rate limiting and cpu usage limiting of the platform.

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

> If you see weakness in this plan that are not already discussed,  
> please share. Or submit patches :)

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

Michael