[OLPC Security] Please read the spec and the discussion first, thanks.

Albert Cahalan acahalan at gmail.com
Sat Dec 1 01:48:02 EST 2007


Michael Stone writes:
> Adric,
>
> 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.

By "unrelated activities" do you mean that multiple instances
of Browse will share the same UID? If so, that needs fixing.
In the long term, throw-away SE Linux security info might be
better than throw-away UIDs. It's a bit more powerful, and it
will ultimately be more compatible and thus more acceptable.

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

This is one of the more troublesome problems. It does effect "only"
the one activity. The browser is quite a lot unfortunately.
Avoiding usage of shared data would be good. Second best would be
to treat the shared data as being both hostile and volatile.

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

datastore: user consent, so no serious worry
clipboard: user consent, so no serious worry
DBus: needs to be blocked
X: note the new SE Linux stuff for X
network: activities must request this at install time

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

For gen2, make sure the CPU supports the NX bit.

If at all affordable, get a 64-bit address space.
This makes address space randomization far more effective.

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

Network rate limiting probably belongs in the school server.
This would ensure that each student gets a fair share of the
internet connection, no matter how many programs they run.

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

Fortunately avahi seems to have a solid containment design.


More information about the Security mailing list