[Qt-qml] SandBox loader

[Girish Ramakrishnan]

Hi Andriano,

On Fri, Oct 21, 2011 at 3:35 AM, Adriano Rezende
<adriano.rezende at openbossa.org> wrote:
> Hi,
>
> I think sandbox support would be a really nice feature to have for the
> Loader component in QtQuick2. I've implemented a SandBoxLoader just to

+1 for that. We have a similar requirement here where we have an app
store which provides pure QML apps. Currently, it's all too easy for
the apps to mess with the parent state and properties.

(Since there is no sandboxing support in QtQuick1, we are actually
exploring an out-of-process approach for apps with composition done by
wayland)

> prove the concept using QtQuick1. It's in the following branch:
>
> http://gitorious.org/qmlarsenal/qmlarsenal/commits/sandboxloader
>
> The main goal is to avoid loaded items to read or change data outside
> its own scope. This feature is mandatory when you have to load 3rd
> party plugins in your application in a safe manner. Normally, loaded
> items have full access to top level properties and elements, leading
> to a security breach. One can change a QML plugin to steal information
> or basically make a mess in the application logic/design.
>
> Follows an usage example:
>
> Item {
>    property string abc: ""
>
>    SandBoxLoader {
>        source: "FooBar.qml"
>    }
> }
>
> // FooBar.qml
> Item {
>    Component.onCompleted: print(abc) // that will result in ReferenceError
> }
>
> I've also hacked the SandBoxLoader parent property to avoid parent
> hijacking. That will prevent an user to walk in the parent hierarchy,
> in the attempt to change or access 'hidden' information, like the
> following:
>
> // FooBar.qml
> Item {
>    Component.onCompleted: print(parent.parent["abc"]) // this will not work too
> }
>
>
> I have some questions regarding QDeclarativeEngine though. The first
> one is if it's safe to create multiple instances of QDeclarativeEngine
> in a application? There are some internal limitations that could lead
> to unexpected behaviors? The reason I ask that, it's because each
> SandBoxLoader creates its own engine in order to avoid sharing the
> same root context of the main engine.
>

I understand you had to take the above approach of creating a new
engine since you are working outside the QtQuick code, but it would be
great if we can somehow just limit the scope and use the same engine.
Our apps still need access to the various context properties to do
anything useful.

Girish