[Bf-committers] Python security - proposal

[Sergey Sharybin]

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