[Bf-committers] Python sandbox

[Benjamin Tolputt]

Brecht Van Lommel wrote:
> First is that there is a difference between python scripts, one
> category is scripts to extend blender like exporters. These
> fundamentally can't run inside a sandbox since they need to access
> files. 
>   

This is, indeed, not new and I know it has been mentioned multiple times
in this "thread" given I've mentioned it more than once :)

The fact of the matter is exporters/importers need to access the file
system to work. That is basically the definition of their existence -
moving data between Blender's internal state to the file system & back.

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

Python has an unofficial design foundation that developers should
"extend Python" with their application rather than "embed Python" into
their application. As such, Python exposes everything one would need in
an application platform - file access, network sockets, operating system
calls, etc. Unlike Java (another extend vs embed platform), this was all
done on the assumption that you wouldn't WANT to limit the virtual
machine running Python from accessing these resources. Other parts of
the system get written on the (valid) assumption the unsecure
functionality will be exposed and so removing file/socket access & the
like becomes an exercise in "hunt the bug" throughout the entire Python
platform/standard library.

Other languages / virtual machines are designed with an "embedding"
mentality. You need to explicitly expose the functionality you want to
use in a script to the virtual machine. Most of the good ones come with
standard libraries to access these features but they can be disabled
with the commenting of a handful of lines at most. In addition, the best
embedded virtual machines give you explicit hooks (or outline the
internal code to change) enabling the end user to override the memory
allocation & CPU usage (i.e. byte-code instructions run without break).

Also, the Firefox analogy is a good one to use. There are two levels of
scripts Firefox runs - the "plugin scripts" which can access your
hard-drive, use Firefox services to retrieve data online, etc and then
there are "content scripts" - the JavaScript that gets run in your
browser when you navigate to a site using it. Unless some explicit
exception is in place - the JavaScript from the web-pages cannot access
the content of your hard drive because it was never given access to the
classes/functions that allow this. However the plugin scripts DO have
the capability of accessing these services because the JavaScript VM
adds classes/functions to allow this. The browser downloaded scripts are
"sand-boxed" like we would desire our scripted constraints & rig drivers
to be whereas the Firefox add-ons are given more functionality like we
desire our import/export scripts to be. Where bugs in this show up, it
is generally not so much to do with the sand-boxing as memory overruns &
the like that are a separate problem Blender would have to deal with anyway.

In summary, sand-boxing is not hard provided you use the right platform
nor does it need "continuous attention". You set up the trusted &
untrusted virtual machines with the functionality they are allowed to
have and that is all. Adding "exceptions" is easy enough, flag the
scripted constraint / driver as requiring access to the file system, add
the file system functionality to the scene VM and raise a warning when
opening it.

-- 
Regards,

Benjamin Tolputt
Analyst Programmer