[Bf-committers] Python security - proposal

Jürgen Herrmann shadowrom at me.com
Mon Jun 10 22:37:27 CEST 2013


You are right ;)
I bet Campbell will come up with a decent proposal.

Am 10.06.2013 um 21:47 schrieb Sergey Sharybin <sergey.vfx at gmail.com>:

> Yes, sandboxing shouldn't be in the list "to be started with" for sure :)
> 
> But oops, i've read original message not careful enough, pardon. Current
> proposal actually proposes Campbell to investigate possible ways of making
> blender safe. So yeah, security stuff is still goes deep enough, but i'd
> wait for final_0 proposal before discussing the topic further or trying to
> give an advice :)
> 
> 
> On Tue, Jun 11, 2013 at 12:05 AM, Jürgen Herrmann <shadowrom at me.com> wrote:
> 
>> Hmm...
>> 
>> First of all we should assume that Linux user won't usually run blender as
>> root or in a sudo environment. So a "rm / -rf" attack shouldn't work by
>> default.
>> I think Windows is the real problem here, nearly every windows user (at
>> least at home) has Admin privileges.
>> I don't know how OSX handles this but under the hood it's a unix too, so
>> it might be less problematic.
>> 
>> I'm afraid that our windows user base would be the most vulnerable. Sand
>> boxing in windows can be done but this requires much work and very careful
>> evaluation to maintain usability.
>> 
>> We should start small and look at the PGP signing possibility first. This
>> could also incorporate a third party signing process. For instance some
>> signing authority sort of thing.
>> E.g. Someone sends in his addon to blender.org and after a security check
>> we sign the addon and send it back to the developer for him to distribute
>> it.
>> But this would be a very time consuming procedure for both us and the
>> script dev because every change has to be approved by someone :(
>> So I don't think we could do this with our current resources.
>> 
>> The other possibility is to store the public keys of approved addon
>> developers in a certificate store at blender.org and the devs self sign
>> their addons and blender checks the signature with the PGP key server.
>> 
>> Unsigned addons should then be prevented to execute auto run scripts.
>> 
>> Just a little brainstorm ;)
>> /Jürgen
>> 
>> Am 10.06.2013 um 19:28 schrieb Sergey Sharybin <sergey.vfx at gmail.com>:
>> 
>>> Couple of things,
>>> 
>>> - All this stuff around "autorun scripts" is not sufficient. There're
>> lots
>>> of other ways to inject malicious code -- for example, using eval("import
>>> os; os.system('rm -rf /')") as a driver for default cube rotation. Also,
>>> for my knowledge freestyle uses scripts for linestyles, which also could
>>> contain malicious code.
>>> Here we could simply make it so if file is not trusted drivers, hooks,
>>> linestyles and so does not run at all.
>>> - Blend files are not the only way to distribute malicious code, we also
>> do
>>> have addons. Think this is rather easier to distribute malicious code via
>>> some useful addon than via .blend file.
>>> Afraid here we've got the only way -- implement sandbox for scripts. But
>>> technically speaking we had some addons during mango which would fail to
>>> run in a sandbox. So this could backfire on usability.
>>> - Marking .blend files as trusted shall be based on some kind of PGP, so
>>> you'll sign the .blend file and other would be able to detect whether
>> it's
>>> indeed your file or not. Using PGP would also guarantee no one is able to
>>> modify signed file and make it unsafe anymore.
>>> 
>>> Not as if i consider proposal bad or useless, but just issues are in fact
>>> foes much deeper. Unfortunately :(
>>> 
>>> P.S. As an alternative to PyPy could think of a process-based sandboxing.
>>> Meaning scripts would be run in a separate process which is being
>>> sandboxed. This could use cgroups, selinux and stuff like that. The most
>>> recent link in the head appears this:
>>> https://code.google.com/p/chromium/wiki/LinuxSUIDSandbox But other
>>> platforms would require more work. But that's just details which could be
>>> useful for that one who'll be sandboxing stuff in blender :)
>>> 
>>> 
>>> 
>>> On Mon, Jun 10, 2013 at 2:58 PM, Ton Roosendaal <ton at blender.org> wrote:
>>> 
>>>> 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
>>>> 
>>>> _______________________________________________
>>>> Bf-committers mailing list
>>>> Bf-committers at blender.org
>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>> 
>>> 
>>> 
>>> --
>>> With best regards, Sergey Sharybin
>>> _______________________________________________
>>> 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
> 
> 
> 
> -- 
> With best regards, Sergey Sharybin
> _______________________________________________
> 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