[Bf-committers] Python sandbox

[Brecht Van Lommel]

Hi,

On Thu, Mar 18, 2010 at 1:51 AM, Benjamin Tolputt
<btolputt at internode.on.net> wrote:
>> To sum up my opinion, sandboxing is very hard and not something we can
>> solve once, it requires continuous attention, so let's not even try
>> it. Instead, the install addon operator should warn about security
>> problems, and loading a .blend file with scripts should become easier
>> for users.
>>
>
> Actually, sand-boxing scripts is quite easy provided you use a platform
> that supports it. Python currently does not support this so the task
> seems insurmountable; but only so long as you look through the Python
> lens. It is quite simple to sandbox applications using Lua - simply
> don't give them access to the unsecure functionality. If you don't want
> the user reading/writing files not explicitly handed to them? Then don't
> give them access to the "io" library (by excluding it from the VM's
> initialisation). Don't want to give the person access to the operating
> system, don't add the "os" module to those accessible by the VM. And so on.

I don't think making the Blender API safe is easy. Some examples of
things that could be exploited:
* .blend/image/sound save operators
* render animation operator
* physics systems point caches writing to disk
* open file browser + run file delete operator
* binding keymap or buttons to an operator
* compositing file output node
* register operator to override .obj exporter

And then there are of course the more complicated ones, memory
corruption, buffer overruns, etc now become security issues. I bet you
can find dozens of indirect an non-obvious ways to do damage. Now, you
can try to figure out all those cases and add checks for them, but
doing this well is really hard. Security issues in web browsers don't
happen because they forgot to disable access to the IO module. And as
new features are added to Blender this does require continuous
attention.

Brecht.