[sugar] Initial Security Patches
Marco Pesenti Gritti
Wed Aug 1 08:04:00 EDT 2007
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:
* 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.
* Plug in the security service, enabled conditionally if the Bitfrost
* 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
On the Sugar side 1 is going be a bit of work, while 2 is trivial.
More information about the Sugar-devel