[sugar] Initial Security Patches

[Marco Pesenti Gritti]

On 8/1/07, Dan Williams <dcbw at redhat.com> wrote:
> On Tue, 2007-07-31 at 21:45 +0200, Marco Pesenti Gritti wrote:
> > Hello,
> >
> > thanks for the explanation, it clarifies a lot of things.
> >
> > As I just said to Ivan and coderanger on irc we needs to be clear on
> > the actual goals for Trial-3. In particular I'd like to know:
> >
> > 1 Are we aiming to enable this by default for Trial-3
>
> Yes.  If activities in containers don't go into Trial 3, they will not
> get into FRS.  They don't have to be locked down at all, just have
> activities launched in containers.  We just have to figure out by
> Trial-3 if people can fix the bugs that come up.  If they can't, we rip
> containers back out and re-evaluate the security position.
>
> > 2 Are we aiming at pushing one-instance-per-process for Trial-3
>
> We may just end up whitelisting EToys and Browse as
> multiple-instance-per-process activities, and just accept that one
> Browse instance can interact adversely with all other instances.  I
> don't think we've  made that call concretely yet though we did discuss
> it on the train today.

OK. So how do we get there? My feeling is that we should do it in three steps:

1

* Remove the factory service from Sugar and move to
one-instance-per-process. (Btw service_name in the activity.info
wouldn't make a lot of sense anymore, we should probably rename to
bundle_id or bundle_name).
* Implement a single instance mechanism in Browse and Etoys.

2

* Plug in the security service, enabled conditionally if the Bitfrost
service exist.

3

* Do some testing and when stuff works well enough enable the Bitfrost
service by default on the images.

Since one-instance-per-process is a Trial-3 goal, I don't see a lot of
value in trying out Bitfrost + multiple instance factory before. We
would risk to end up debugging something quite different from the
final thing.

On the Sugar side 1 is going be a bit of work, while 2 is trivial.

Thoughts?

Marco