[Bf-committers] Python security - proposal

[Ton Roosendaal]

Hi Daniel,

I fully agree that such popups are quite meaningless, and will result in annoying users (because either the blend doesnt work, or they risk getting their hd wiped ;)

That's why it needs to be combined with point three:

>> 3) Implement a friendly (easy to use) way for marking/defining .blend
>> files to be always be trusted.

That should work for studio projects as well to mark files 'safe' to autorun scripts with. This way you can control which files should get warnings, and which not.

Even then, it's a quite weak solution. Having Python execution for simple (animator) scripts secured by definition would really be best. I won't give on that, but unfortunately no knowledgable coder considers it very feasible.

Meanwhile - the option to always trust everything can be in your user settings, so for power users nothing has to change really. 

We can also choose to not do anything. But from BF perspective (i.e. offering millions of downloads per year to a huge audience) I don't think it's a responsible act. In the unfortunate case some troll does manage to harm a large group of Blender users, it would be something they'd morally could blame BF for. 

-Ton-

--------------------------------------------------------
Ton Roosendaal  -  ton at blender.org   -   www.blender.org
Chairman Blender Foundation - Producer Blender Institute
Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands



On 9 Jun, 2013, at 21:20, Daniel Salazar - 3Developer.com wrote:

> 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
>> 
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers