[Qt-qml] SandBox loader

[Adriano Rezende]

Hi Girish,

On Mon, Oct 24, 2011 at 11:01 AM, Girish Ramakrishnan
<girish at forwardbias.in> wrote:
> 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
>
> (Since there is no sandboxing support in QtQuick1, we are actually
> exploring an out-of-process approach for apps with composition done by
> wayland)

Yes, I think this a common requirement.
Currently, an out-of-process approach is the only safe approach.
How are you handling with QML integration, like relative opacity and
inherited transformations?

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

Yes, this feature should reside inside QtQuick code. That would
provide a clean and safer integration.
At least, we need to have an option to block unknown C++ plugins to be
loaded by 3rd party plugins.
In the SandBoxLoader example, one could easily surpass the parent
barrier creating an extended C++ element and could also kill the
application at any time.

I think two main features could be provided:

- Provide a filter mechanism for imports (block unknown/local C++ plugins)
- Create a scope barrier (we could still inject explicitly useful
properties through the Loader object, so the loaded item could access
them)


Br,
Adriano