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

[Michael Stone]

On Sat, Dec 01, 2007 at 01:48:02AM -0500, Albert Cahalan wrote:
> By "unrelated activities" do you mean that multiple instances
> of Browse will share the same UID? If so, that needs fixing.

The difficulty is that forcing activity instances into a 1-1
correspondence with uids exacerbates our current problems with memory
usage and activity launch time. Otherwise, I'm fine with the idea.

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

Please explain further, at your convenience.

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

I argued strongly that activity configuration files are properly stored
in the datastore along with every other piece of user-generated data.

People who believe that Sugar should be able to run mostly-unported
software argued that they needed a persistent unix file-system on which
to store their data. Hence the current semantics of 'data'.

> datastore: user consent, so no serious worry

First, access to configuration files does not require user consent.
Second, today, neither Sugar nor the DataStore perform access checks.
(See #2328 and #3801). Changing this is one of my higher priorities.

> X: note the new SE Linux stuff for X

I assume you're referring to XACE here?

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

Hmm. Curious thought.

> Fortunately avahi seems to have a solid containment design.

Very true. Unfortunately, much of our software does not... yet. :)

Michael