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

Ton Roosendaal ton at blender.org
Fri Jun 7 18:03:14 CEST 2013


Hi Shrinidhi,

> Why not have a script that ships with blender, which can be run
> individually,  which checks the blender file for scripts  and informs the
> user if it is malicious or safe ?

That's interesting to check, but I don't like to make users responsible for checking each .blend they want to load. My preference is a way that's relatively safe and works out of the box for everyone (except system administrators :).

> 1 : Changing blenders default behavior for running scripts is like killing
> a few scripters in studios using blender.

That is only true if we stick to how it works now. We can find ways to either force scripts to become add-ons or to mark .blend files or scripts as trusted for own use and studios.

-Ton-

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



On 7 Jun, 2013, at 16:37, Shrinidhi Rao wrote:

> On Fri, Jun 7, 2013 at 4:42 PM, Ton Roosendaal <ton at blender.org> wrote:
> 
>> Hi all Pythoneers,
>> 
>> Scripters are important for Blender, but just like the C developers they
>> have a responsibility for users out there. A good proposal for security has
>> to come from you as experts first.
>> 
> 
> Why not have a script that ships with blender, which can be run
> individually,  which checks the blender file for scripts  and informs the
> user if it is malicious or safe ?
> The script can have a way to update a set of rules that marks the files
> safe or unsafe. May be blender institute can maintain a database and the
> script will auto-update the rules.
> People responsible for the python API can keep updating the database
> incrementally.
> 
> Now why a different script? .
> 1 : Changing blenders default behavior for running scripts is like killing
> a few scripters in studios using blender.
> 2 : it can be run individually by the security conscious people . at least
> they will have a way to check if a blend file is evil or good .
> 3: for large deployments it can be run in batch mode to check multiple
> files at once .
> 
> 
> This way we can make the users happy . at least they will have a way to
> tell what the blend file is up to .
> In a studio we need not worry about it as there are proper user permissions
> and policies already implemented.
> 
> 
> 
>> 
>> If this discussion just leads to marking every idea as impossible (Python
>> is insecure by design) then we should have a big problem with keeping
>> Python in Blender. Fork it, sandbox it, or move to LUA.
>> 
>> This is not at all constructive! .
> Arguing against using python and replacing it with a crippled scripting
> language is as good as telling professional studios users to stop using
> blender directly. it will not help blender in anyway. first thing they see
> is how can data be interchanged between softwares . no studio will dump
> their existing softwares and start using blender entirely for all their
> production stages . blender should be able to communicate with other
> software and a restricted scripting language will not help blender or its
> users.
> 
> as it is, i am already feeling crippled without a socket based command port
> in blender . there is no way to send a command to blender like opening
> files, linking etc! . well . this is not needed if we have only a blender
> specific pipeline. but if we want to keep our pipeline UI out of blender
> then its very useful
> 
> 
> 
>> Let it be clear: we're making Blender here, which is meant to be a 3D
>> creation tool. It's not a Python development environment. Users come first,
>> scripters and coders second. So... stop being smartasses and think
>> constructive a bit.
>> 
>> 
> A 3D creation tool without a powerfull scripting api is useless nowadays,
> at least for professional users.
> Users come first . yes.. i totally agree with you . but the users always
> improve and always want more out the software once they become aware that
> they can do certain things in blender . And the same users who wanted too
> much security will be annoyed by the same security measures once they come
> out of their hobbyist attitude and become scripters and coders.
> 
> 
> 
>> -Ton-
>> 
>> --------------------------------------------------------
>> Ton Roosendaal  -  ton at blender.org   -   www.blender.org
>> Chairman Blender Foundation - Producer Blender Institute
>> Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
>> 
>> 
>> 
>> On 7 Jun, 2013, at 12:08, Domino Marama wrote:
>> 
>>> On 06/07/2013 10:21 AM, Ton Roosendaal wrote:
>>>> Hi Campbell,
>>>> 
>>>> I don't know enough about Python internals, so I depend on someone to
>> help designing a sane way to handle security risks here. There must be ways
>> we can help users?
>>>> 
>>>> Look for example at the standard UI scripts. Apart from 1 case, there's
>> no "import os" anywhere. Same goes for essential scripts riggers or
>> animators use.
>>>> 
>>>> So, why not add a provision in Blender code to check on such cases.
>> Just don't allow import of any module = safe script? In all other cases:
>> needs to be explicitly permitted to run.
>>>> 
>>>> Something like this would make a "trusted source" option on file
>> loading more useful. Right now, unticking "trusted source" is almost
>> equivalent to "disable useful features".
>>>> 
>>>> 
>>>>>> oh = 'SOS HELP!'
>>>>>> ohoh = __import__(oh[1:3].lower())
>>>>>> ohoh
>>> <module 'os' from
>>> 
>> '/home/domino/Applications/blender-2.67-linux-glibc211-x86_64/2.67/python/lib/python3.3/os.py'>
>>> 
>>> On Linux distros where system Python is used, I doubt anything can be
>>> done to prevent the import function from being used.
>>> 
>>> Load Blender with a console, check there's the startup message on it.
>>> Then paste this into say the frame number field..
>>> 
>>> eval("__import__('os').system('clear')", {})
>>> 
>>> Now check console again.. Just checking scripts for imports isn't enough.
>>> _______________________________________________
>>> 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
>> 
> 
> 
> 
> -- 
> 
> regards
> - shrinidhi
> 
> 
> Even god fails to understand a human until his death!
> http://www.linkedin.com/in/shrinidhi666
> https://github.com/shrinidhi666
> 
> 
> 
> <http://www.imdb.com/name/nm3025616>
> _______________________________________________
> 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