[Bf-committers] Python security - proposal

[Daniel Salazar - 3Developer.com]

Steps to bypass all the measures being proposed in the sake of "security":

1. Take a sintel rig file and add the two liner needed to delete your HD in
line 700 of one of the scripts.
2. People download this blend file and of course it doesn't work because
the blend file was designed to use scripts right? After taking a quick look
to the scripts they look legit.
3. A message appears saying something like "Sorry this file relies on
python scripts to autorun and that is disabled by default".
4. User proceeds to enable the loading of scripts.
5. User's HD is deleted.

IMO you're not solving any security loopholes with this stuff. Just making
it harder for blend files to be run as *they were designed*. It's easy to
say "just change the default" but defaults don't work with teams of mixed
environments, with members in different parts of the world, different
levels of blender experience (or none at all).

Again, python in Blender is everywhere! This is pretty much a flag that
tells Blender to NOT work as intended because some security issue that has
never happened.

Please come up with a proper solution before pushing an idealistic method
that will do nothing to protect users in the real world.

kind regards,

Daniel Salazar
patazstudio.com


On Sun, Jun 9, 2013 at 7:02 AM, Ton Roosendaal <ton at blender.org> wrote:

> Hi all,
>
> Back to practical solutions we can work on for the next release!
> Here's a proposal I think has a wide consensus:
>
> 1) "Trusted source" for autorun scripts gets default disabled.
>
> 2) On loading a .blend with autorun script, we notify a user of that. How
> that UI will work exactly has a number of solutions we can investigate
> further. I suggest Campbell to investigate it and test some ideas and
> propose that here.
>
> The above should be a real 2.68 target.
> Further actions we can take:
>
> 3) Implement a friendly (easy to use) way for marking/defining .blend
> files to be always be trusted. Also here a number of solutions are
> possible, like preset directories for where such files are located, or a
> way to sign personally saved files. Or both.
>
> I propose Campbell to investigate that further too with some people and
> come with a final proposal for it.
>
> 4) Cleanup Blender file writing code itself as well. Like stop using /tmp
> for files, and enforce relative paths for (automatic) output file writing.
>
> 5) Figure out if there's any way to detect malicious scripts...
>
> 6) Kick Python.org and/or support the PyPy project to get 3.x Python
> secured somehow.
>
>
> -Ton-
>
> --------------------------------------------------------
> Ton Roosendaal  -  ton at blender.org   -   www.blender.org
> Chairman Blender Foundation - Producer Blender Institute
> Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
>
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>