You are right ;) I bet Campbell will come up with a decent proposal. Am 10.06.2013 um 21:47 schrieb Sergey Sharybin <sergey....@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 <shadow...@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....@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 <t...@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 - t...@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 <t...@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 - t...@blender.org - www.blender.org >>>>>> Chairman Blender Foundation - Producer Blender Institute >>>>>> Entrepotdok 57A - 1018AD Amsterdam - The Netherlands >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Bf-committers mailing list >>>>>> Bf-committers@blender.org >>>>>> http://lists.blender.org/mailman/listinfo/bf-committers >>>>> _______________________________________________ >>>>> Bf-committers mailing list >>>>> Bf-committers@blender.org >>>>> http://lists.blender.org/mailman/listinfo/bf-committers >>>> >>>> _______________________________________________ >>>> Bf-committers mailing list >>>> Bf-committers@blender.org >>>> http://lists.blender.org/mailman/listinfo/bf-committers >>> >>> >>> >>> -- >>> With best regards, Sergey Sharybin >>> _______________________________________________ >>> Bf-committers mailing list >>> Bf-committers@blender.org >>> http://lists.blender.org/mailman/listinfo/bf-committers >> _______________________________________________ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers > > > > -- > With best regards, Sergey Sharybin > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers