[Bf-committers] Python security - proposal

Sergey Sharybin sergey.vfx at gmail.com
Mon Jun 10 21:47:25 CEST 2013


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


More information about the Bf-committers mailing list