Discussion:
[OLPC Security] [sugar] Web activity not containerized?
Michael Stone
2007-12-23 01:50:51 UTC
Permalink
Running an activity as the same user every time will not offer
a way for that activity to attack any other activity. This should
be the major concern.
The part that concerns me is that there are lots of activities derived
from Browse at the moment. This means that one of three things is going
to happen:

1) Too much isolation: all of the different browser variants will have
separate profiles

2) Too much sharing: We run them all as the same user and a malicious
one can come along and corrupt the whole shebang

3) Just right: We work out a decent protocol for them to play together

Causing all the instances of *Browse* to run as the same user might be a
decent band-aid for the immediate problem but it is not, in my opinion,
a good solution for the problem of 'we don't know how to make software
using xulrunner play well with others'.
Letting the *.xo file request a single UID is a good idea.
This helps get initial ports running.
There's a big difference between an annotation that says 'run me as the
same uid each time' and one that says 'run me as _this_ uid every time',
or, equivalently, one that says 'run me as the same uid as that other
guy over there'.

As I suggested above, I don't think the 'run me as the same uid every
time' is anything but a band-aid and I'm happy, for the time being, to
stick with the band-aid that I've got (de-isolating Browse).

The other two 'solutions' have some obvious flaws of their own.
If an activity opens itself up for attack, then the author of
that activity doesn't get a gold star. The activity is not a
good example to learn from. In general though, the activity is
not a problem. There is no critical need to protect activities
from themselves.
I agree that there's no need to protect one instance from itself, but I
feel quite strongly that it is important to force authors to be explicit
about the communication that takes place between separate instances.

Others should feel free to disagree in the form of justified patches so
that we can publicly consider the merits of their proposal.
(actually the browser is special, but nobody has proposed to
start a new instance for each web site visited -- the browser
is already handling multiple security contexts under one UID)
If I believed it were feasible from a memory and performance standpoint,
I would definitely be advocating that we start new instances for each
web site visited. State leakage between web pages is one of the major
classes of attacks on web browsers, no?

Michael
Marcus Leech
2007-12-23 02:15:02 UTC
Permalink
Post by Michael Stone
I agree that there's no need to protect one instance from itself, but I
feel quite strongly that it is important to force authors to be explicit
about the communication that takes place between separate instances.
Others should feel free to disagree in the form of justified patches so
that we can publicly consider the merits of their proposal.
The activity that I "fear" the most from the point of view of getting
"compromised" (that is, remote-code-execution)
is Browse. And our band-aid is to de-isolate it. I understand *why*,
but it still seems a little nausea-making to me.

I don't instantly have a suggested cure, of course, so I'm willing to
live with band-aids.

Browsers are big, hairy, and complicated. Which is precisely the kind
of fertile ground in which remote exploits
germinate and grow.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
Url : http://lists.laptop.org/pipermail/security/attachments/20071222/3b95d510/attachment.pgp
Michael Stone
2007-12-23 02:33:43 UTC
Permalink
Post by Marcus Leech
The activity that I "fear" the most from the point of view of getting
"compromised" (that is, remote-code-execution)
is Browse. And our band-aid is to de-isolate it. I understand *why*,
but it still seems a little nausea-making to me.
Help me get out from under #5033 in a reasonably solid fashion and I'll
be happy to devote more energy toward finding a solution for #5489 that
makes us happy.

My approach thus far is available at

http://dev.laptop.org/git/users/mstone/nss-rainbow

Progress has been slow to date because the API is not very well
documented, I'm paranoid about memory errors, and I'm even more paranoid
about concurrency.

(Note: I also considered libnss-sqlite but decided that since
a) it looked rather unmaintained to me, and
b) I'm not a proficient SQL writer,
it would be unlikely to lead to any productivity gain if I'm doing the
implementation.)

Michael

Loading...