[Bf-committers] Please turn off Auto Run Python Scripts by default

Ton Roosendaal ton at blender.org
Wed Jun 5 14:35:16 CEST 2013


Hi,

Here's just some ideas to investigate:

1) Better location for temp saves

- remove /tmp/ usage from our default, and move it to sane a path inside user space. We can call this sandbox or so, which (on first use) could also be confirmed by users to be used as such.

- sandbox paths could simply be the ones without / or // or C:\\ etc.

2) Communicate to users all saving C/C++ code well

- Each save of a file should be printed in terminals.

- Only allow non-user approved saves to files in sandbox (like temp files). 

- All other saves by tools should go by design via user confirmations (popup "save-over"). For tools with standard output paths (bakes, caches, anim render) only relative paths should be allowed (without confirmation).

3) Formalize definition of "trusted source" better.

- Any .blend file with absolute output paths could be marked untrusted by default.

- Macs (and Windows?) already have a way to detect a downloaded file, which can marked to be untrusted .blend.

- Blender files can also get a User identifier struct, which can be used for various ways to mark files 'trusted' or not. 
In its simplest implementation it can just store an identifier string (copied from userpref) to mark files as "saved by myself". 

4) Replace Python's os module

- For standard releases, the os module could follow same file save rules as our C code does. Untrusted files could default be allowed to use sandbox only.

-Ton-

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



On 5 Jun, 2013, at 13:24, Ton Roosendaal wrote:

> Hi,
> 
> I've checked some history of past discussions (including sandboxing Python) and to me it seems we still accept too much risk here. As a team (and for me as Blender Foundation chairman) I feel it's a big responsibility to not waive away so easily.
> 
> More over - it's a disaster waiting to be happening one day. It would be unforgivable if we didn't at least help users to have a basic security in place.
> 
> The discussion is also getting too much complicated by knowledgable people who point out that there's always another vulnerability or other methods to bypass any security feature. IMHO that's irrelevant, should never be a reason to ignore it altogether.
> 
> We should be able to bring down this topic to a basic and sensible minimal protection we provide for users.
> 
> Can we form some kindof workgroup to investigate it further and define a proposal for actions? Or a roadmap? 
> 
> And: is there a consensis to make the default startup install have 'autorun' disabled, with a notifier in the top header about it?
> 
> -Ton-
> 
> --------------------------------------------------------
> Ton Roosendaal  -  ton at blender.org   -   www.blender.org
> Chairman Blender Foundation - Producer Blender Institute
> Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
> 
> 
> 
> On 5 Jun, 2013, at 8:25, Campbell Barton wrote:
> 
>> On Wed, Jun 5, 2013 at 4:21 PM, Knapp <magick.crow at gmail.com> wrote:
>>> On Wed, Jun 5, 2013 at 8:03 AM, Knapp <magick.crow at gmail.com> wrote:
>>>> As a normal hobby users, the biggest risk that I see is downloading a
>>>> blend from the net and opening it. This is not something we are likely
>>>> to give up. So, warning or not, what good is it? I need some way to
>>>> know if the file is good or bad. I don't see an answer. I would say a
>>>> good third of the users or more download blends for learning at least
>>>> and often for producing their own stuff.
>>> 
>>> What might be much more useful is a program that load a blend and tell
>>> me what it might do. For example, does it run scripts, does it have
>>> crazy large data sets? If it runs scripts then it should be able to
>>> show me them. It should look at the data sizes that the blend will use
>>> and make guesses if it is too large. Naturally it should only open the
>>> blend as data and not as blender would.
>>> --
>>> Douglas E Knapp
>> 
>> Such a tool isn't so hard to write, see this python module which loads
>> up blend files without using blender.
>> http://blender-aid.googlecode.com/svn/trunk/src/blendfile.py
>> _______________________________________________
>> 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



More information about the Bf-committers mailing list