[sugar] DOS via D-Bus

[John (J5) Palmieri]

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.

> 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?

> 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.

-- 
John (J5) Palmieri <johnp at redhat.com>