On Mar 20, 2007, at 19:08 , John (J5) Palmieri wrote:
On Tue, 2007-03-20 at 10:44 +0100, Bert Freudenberg wrote:
Hi folks,
the Bitfrost spec only touches briefly on D-Bus. So I was
wondering ... At the very simplest, an activity could ignore the quit
message sent from the frame - is it going to get killed after a
timeout? Or, it could flood the D-Bus with a lot of messages.
Not sure what you mean by quit message but D-Bus will ignore an app
that
tries to spam it.
When you choose "quit" in the frame's activity menu a message is sent
to the activity asking it to quit.
So, are there general mechanisms in place to defend against this? As
I understand it, sharing "active documents" which contain code are
explicitly encouraged in the educational vision of the project. Or
does an activity that allows "active" documents have to provide their
own sandbox to try to minimize what the code could do? Like, if we
made D-Bus accessible to JavaScript in the browser, would that be a
Bad Thing? If we allowed Python as a scripting language in the
browser? Which I would find immensely cool.
Having D-Bus accessible in the browser is no more dubious than
having it
accessible on the client. The question is what do you export over the
bus and are they safe to be accessed remotely?
Well, for the time being we'd only expose what is necessary to
communicate with Sugar. I was more concerned about maliciously
sending messages to other d-bus services.
The problem at hand for me is that we wanted to switch etoys to
handle d-bus itself for quite some time. This would, for example, get
rid of the Python wrapper which would free up some valuable system
resource. A few months ago everybody thought this was a good idea,
and actually encouraged to develop a non-Python activity, if only to
make sure the protocol used really is independent of the
implementation language.
However, this would potentially give direct d-bus access to every
etoy. I think it would not be worse than sharing a Python activity
that could cause havoc on the d-bus easily. But I'd like to hear
other's opinions on that.
Exactly. It is no more dangerous than using python. Of course if the
code can be executed by simply going to a page we need to be a bit
more
sandboxed. For instance we wouldn't want a JavaScript page to be able
to dim the screen.
Well, SJ asked for simple etoy project launching by clicking on a
link in a web page. And when that project is run, it can execute
arbitrary Squeak code, so without specific counter-measures it could
freely access d-bus. It's pretty much as if you'd download and
execute arbitrary Python code.
Before loading a foreign project we enable the squeak sandbox, which
for example limits file access to one specific scratch directory. A
project is considered foreign if it was not signed with the users
private key (this is the key that is generated when running etoys for
the first time). So if you're saying restricting d-bus access would
still be valuable, we could arrange that only a specific set of d-bus
messages could be sent or received once the sandbox is enabled.
- Bert -
_______________________________________________
Sugar mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/sugar
