[OLPC Security] Re: [sugar] DOS via D-Bus

[Bert Freudenberg]

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 -