Re: [Bf-committers] "Security" gets in the way
On Wed, Apr 28, 2010 at 11:00 AM, Daniel Salazar - 3Developer.com wrote: > In 2.5 since the inclusion of the "trusted source" > option this has done nothing but cause problems everywhere As I was mentioning with Daniel on IRC, I completely agree. These 'security' additions have always caused me more trouble than benefit and I have had the same experiences at my studio in the past. For example: * People loading up files, animating and keying not knowing that python constraints etc had decided to switch themselves off, meaning that when they were enabled again, the animation was screwed * Problems with render nodes on farms not enabling drivers/constraints that you only notice once you get a several hour long render back from the farm This stuff is unnecessary in a studio environment, and costs money directly in wasted time. To paraphrase what I said in IRC, the problem is that this system is trying to solve a problem that a) hasn't existed and b) doesn't actually solve anyway, while at the same time it causing considerable trouble for people who are actually using blender - the cost/benefit equation is way out of whack. There are security risks for any kind of unverified file that you download - it could be a python tool that you download, or for example look at the amount of people who blindly download builds from graphicall.org which could contain anything, or any other files from the internet either. But now we have this current situation designed to satisfy theoretical concerns by people who may not have to deal with the practical consequences. It won't really stop people from getting into trouble, but instead *stops your own work in your own files from functioning*. This is very frustrating and I think something has to change here. Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
Matt Ebb wrote: > This stuff is unnecessary in a studio environment, Agreed. The primary target user-base for the security issue are new & inexperienced users who *will* download material online and install it without thinking about the consequences because they are simply unaware of them. Much like an email virus is targeted at the relatively computer illiterate. I fully accept that there should be an option to turn this thing off completely and have that stick. I have similar "ignore this warning from now on" options in most the applications I put together. > But now we have this current situation designed to satisfy theoretical > concerns by people who may not have to deal with the practical > consequences. This is as theoretical a concern as macro virii which were ignored up until they did alot of damage to alot of poeple. I accept that Blender is a small target and that studios want the capability of controlling any & all security features affecting them (through being able to turn off any & all limitations should they desire to). I do not accept the fact that security is a theoretical problem or that only studios need to deal with consequences. > It won't really stop people from getting into trouble, > but instead *stops your own work in your own files from functioning*. > This is very frustrating and I think something has to change here On this, however, I agree 100%. The current "solution" to the problem is a half-assed solution at best and a hindrance almost all the time. This is not a fault of the developers really, but simply a consequence of Python lacking any real concept of process security. Basically, in choosing to use Python you have to accept the fact that you'll be using *all* of it, security holes and all. It is one of the /cons/ that go with the /pros/ of Python as an "embedded language" which, as the Python core team keep telling us, is not what it was designed for. I think a half-baked solution is worse than no solution at all. With no solution, the problem is more likely to be revisited when there is time and/or a possible answer. A half-baked solution does little to resolve the problem and, by it's very existence, hampers the need to put some real security options into the application. Hacks have a nasty habit of staying in a project for a long time, flawed and cumbersome as they may be, because they get "most of the job done". With security, you either get the job done properly or not at all, because half-solutions are non-solutions. -- Regards, Benjamin Tolputt Analyst Programmer ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
On Wed, Apr 28, 2010 at 12:09 PM, Benjamin Tolputt wrote: > Matt Ebb wrote: >> This stuff is unnecessary in a studio environment, > > Agreed. The primary target user-base for the security issue are new & > inexperienced users who *will* download material online and install it > without thinking about the consequences because they are simply unaware > of them. > I fully accept that there should be an option to turn this thing off > completely and have that stick. I have similar "ignore this warning from > now on" options in most the applications I put together. This is the problem though really - it's not always enough to say 'change the defaults and save the preferences' because inevitably problems still occur. For example some situations in which this caused issues included: * An animator taking some work home to do over the weekend to meet a deadline * Sending files to another studio who was helping us out with rendering * Bringing in and adding in borrowed machines to the render farm (like artists laptops) to help with last-minute rendering power In these situations, it was a matter of quickly installing blender and getting it going, often not by blender experts. It's not as if it was a strictly controlled 'software roll-out' environment - indeed most studios that use Blender (small ones) probably don't have that kind of organised IT infrastructure like you might have in a large corporation. Sure, one can say "oh it's your fault for not enabling the options" but that brings me back to the original point - regardless of whether you want to blame the user or not, the existence of this 'security' does cause real practical problems. Especially in cases like I described above where you're tired and stressed meeting a deadline and the last thing on your mind is going to disable some stupid security preference and saving default preferences. Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
For the record, I am in no-way criticising the developers or what they did in trying to plug the security hole. The issue is that Python has no concept of (nor do their core development team wish to address) process security when used as an embedded language. Python is a language designed to be "extended" not "embedded". Most features have been designed with that lack of limitation in mind, leading to the variety of "exploits" one can use on Blender. Given the axiom of using standard Python for the scripting language of Blender, there are no good solutions. If the Python developers can't/won't address the issue - the best Blender developer is not left with viable options - only unviable ones. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
Matt Ebb wrote: > Sure, one can say "oh it's your fault for not enabling the options" > but that brings me back to the original point - regardless of whether > you want to blame the user or not, the existence of this 'security' > does cause real practical problems. Especially in cases like I > described above where you're tired and stressed meeting a deadline and > the last thing on your mind is going to disable some stupid security > preference and saving default preferences. Well, first thing to note is that I think that the current implementation is not really a solution and needs to be turfed. There is no way of knowing if someone has tampered with a file on a website, so a malicious user need only hack the web-site of someone putting up, say, a useful base rig that was verified in the past as "secure". It is trivial to then link Python code into every file then saved by Blender. Given the fact Python is the problem - I don't see a solution with it as the scripting foundation of Blender as things stand currently. That said, I find the idea that one doesn't want to flick one extra switch on initial setup a relatively weak reason not to include security. There is always going to be a trade-off with security - it is /built-in/ to the whole model of limiting what can be done so as not to compromise/hurt yourself. And not allowing it to be set as the default basically makes it useless (because those most vulnerable will not even know to look for it to turn on). I know & understand your position on this (I've lost count of how many time a missing password or command line flag has meant an overnight data processing run has come out bad); but that doesn't mean I agree with your position that some small hassle ONCE on install outweighs security concerns. Our disagreement is all superfluous though because I think the current security option is worse than none. It both provides an illusion of security AND causes all the hassles (& more?) a real solution would entail. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
added -Y option to enable script execution, this means render nodes don't need to have .B25.blend's eg. ./blender.bin -b -Y myblend.blend -a On Wed, Apr 28, 2010 at 3:00 AM, Daniel Salazar - 3Developer.com wrote: > I have a history of lost work and time with this so called security > features where blender decides to turn off drivers and ignore script links > and so on and you don't notice it until you have worked on a faulty > rig/scene for a long time or you have rendered some heavy frames and have to > do it all over again. In 2.5 since the inclusion of the "trusted source" > option this has done nothing but cause problems everywhere from teaching to > every day jobs; students load rigs that don't work and naturally they do not > know the difference, lost time with clients that in order to review a rig > had to turn on the load py scripts option and they didn't knew about it so > we all loose time, etc. > > Today I sent a render to the farm and when it finished the character was > all wrong.. so I spent a long time changing the .B25.blend files on all 17 > machines (boot with X session, change preference, reboot again). After all > this I launch the render again and when it finished the problem is still > there. It so happens that rendering from command line ignores the .B25.blend > file... so not good. I had to export animation as MDD point cache and import > back as RVKs in order to workaround the missing drivers > > http://www.pasteall.org/12745 > > So my point of view here is: stop playing around with my scene *please*, > it's hard enough to get things working for blender to decide to break some > random part. And this is the point of view of someone with 8 years of using > blender almost every day, imagine someone new trying to figure out this > problems? > > cheers > > Daniel Salazar > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
So the scenario here as I see it is: people who don't know about this leave the loading of scripts off (and are safe from the evil blender hackers out there), next people start having the problems related to this setting and due to it being unusable in production they find out how to disable it everywhere and then they are right where everything started, except from time to time someone forgets to set the flag on and gets a nice headache while wondering why this feature exists in the first place Daniel Salazar www.3developer.com On Wed, Apr 28, 2010 at 2:04 AM, Campbell Barton wrote: > added -Y option to enable script execution, this means render nodes > don't need to have .B25.blend's > > eg. > ./blender.bin -b -Y myblend.blend -a > > On Wed, Apr 28, 2010 at 3:00 AM, Daniel Salazar - 3Developer.com > wrote: >> I have a history of lost work and time with this so called security >> features where blender decides to turn off drivers and ignore script links >> and so on and you don't notice it until you have worked on a faulty >> rig/scene for a long time or you have rendered some heavy frames and have to >> do it all over again. In 2.5 since the inclusion of the "trusted source" >> option this has done nothing but cause problems everywhere from teaching to >> every day jobs; students load rigs that don't work and naturally they do not >> know the difference, lost time with clients that in order to review a rig >> had to turn on the load py scripts option and they didn't knew about it so >> we all loose time, etc. >> >> Today I sent a render to the farm and when it finished the character was >> all wrong.. so I spent a long time changing the .B25.blend files on all 17 >> machines (boot with X session, change preference, reboot again). After all >> this I launch the render again and when it finished the problem is still >> there. It so happens that rendering from command line ignores the .B25.blend >> file... so not good. I had to export animation as MDD point cache and import >> back as RVKs in order to workaround the missing drivers >> >> http://www.pasteall.org/12745 >> >> So my point of view here is: stop playing around with my scene *please*, >> it's hard enough to get things working for blender to decide to break some >> random part. And this is the point of view of someone with 8 years of using >> blender almost every day, imagine someone new trying to figure out this >> problems? >> >> cheers >> >> Daniel Salazar >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > > > > -- > - Campbell > ___ > 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
Re: [Bf-committers] "Security" gets in the way
Hm... To me - as a person coming from the IT security field - there seems to be an interesting conundrum: At some point in the past, someone made the choice of using Python as the pervasive scripting language in Blender. We've all heard through various emails on how it is basically NOT possible to lock down Python to be secure (as well as being outside of the scope of actual language development according to the Python gurus, so it will never happen). At the same time, tons of stuff depends on Python being "fully" enabled, so shutting it off is not really an option as well. From my experience, if an option needs to be turned on/off most of the time for things to work, it will be left at the most convenient setting always, so there really is no value in having the option in the first place. From what I have read so far, the only "real" solution would be to move to a truly "sandboxable"/embeddable scripting language such as LUA, which is not going to happen or to keep running with the existing model of trusting everybody not to screw around with Python scripts. All other solution that I have seen place an unmanageable burden on the user and usually require a central controlling entity (i.e. signed vs. unsigned code having access to restricted functions such as I/O). We should keep this in perspective though. Most other 3D packages currently allow "dangerous" scripting too, so we don't really behave any worse by allowing scripts in the current setting than any other solution. Which is not to say that we shouldn't try to be "better" than the other packages on the long run... Ultimately, I would suggest to abandon Python for a truly embedded scripting solution (i.e. LUA), but that would be a massive change with a huge impact... maybe worth a thought for Blender 3.0. Cheers Remo > So the scenario here as I see it is: people who don't know about this > leave the loading of scripts off (and are safe from the evil blender > hackers out there), next people start having the problems related to > this setting and due to it being unusable in production they find out > how to disable it everywhere and then they are right where everything > started, except from time to time someone forgets to set the flag on > and gets a nice headache while wondering why this feature exists in > the first place > > > added -Y option to enable script execution, this means render nodes > > don't need to have .B25.blend's > > > > eg. > > ./blender.bin -b -Y myblend.blend -a > > > >> I have a history of lost work and time with this so called security > >> features where blender decides to turn off drivers and ignore script links > >> and so on and you don't notice it until you have worked on a faulty > >> rig/scene for a long time or you have rendered some heavy frames and have > >> to > >> do it all over again. In 2.5 since the inclusion of the "trusted source" > >> option this has done nothing but cause problems everywhere from teaching to > >> every day jobs; students load rigs that don't work and naturally they do > >> not > >> know the difference, lost time with clients that in order to review a rig > >> had to turn on the load py scripts option and they didn't knew about it so > >> we all loose time, etc. > >> > >> Today I sent a render to the farm and when it finished the character was > >> all wrong.. so I spent a long time changing the .B25.blend files on all 17 > >> machines (boot with X session, change preference, reboot again). After all > >> this I launch the render again and when it finished the problem is still > >> there. It so happens that rendering from command line ignores the > >> .B25.blend > >> file... so not good. I had to export animation as MDD point cache and > >> import > >> back as RVKs in order to workaround the missing drivers > >> > >> http://www.pasteall.org/12745 > >> > >> So my point of view here is: stop playing around with my scene *please*, > >> it's hard enough to get things working for blender to decide to break some > >> random part. And this is the point of view of someone with 8 years of using > >> blender almost every day, imagine someone new trying to figure out this > >> problems? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
Daniel Salazar - 3Developer.com wrote: > So the scenario here as I see it is: people who don't know about this > leave the loading of scripts off (and are safe from the evil blender > hackers out there), next people start having the problems related to > this setting and due to it being unusable in production they find out > how to disable it everywhere and then they are right where everything > started, except from time to time someone forgets to set the flag on > and gets a nice headache while wondering why this feature exists in > the first place > One could say the same about ActiveX plugins and a wide variety of other security holes. I hate to repeat myself but security is ALWAYS a trade-off. Logins require remembering passwords, file systems have permissions restricting access to files/directories, etc. In a perfect world one wouldn't need to trade-off security against usability; but we live in the real world and such trade-offs happen (& are accepted) all the time. I think the core development team needs to decide whether security will or will not be in Blender 2.5/2.6 because statements like the above are creeping back into the "we don't need security" territory which I thought was resolved. Either there is an accepted need/requirement for security & it is included *or* the task of implementing security is classified as unwanted/unimplementable at this time and it is removed. It would be good to know where things stand because instead of "There is a bug in the security code - fix the bug"; we seem to be getting "There is a bug in the security feature - get rid of security". ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
On Wed, Apr 28, 2010 at 10:35 AM, Remo Pini wrote: > Hm... > > To me - as a person coming from the IT security field - there seems to be an > interesting conundrum: > > At some point in the past, someone made the choice of using Python as the > pervasive scripting language in Blender. We've all heard through various > emails on how it is basically NOT possible to lock down Python to be secure > (as well as being outside of the scope of actual language development > according to the Python gurus, so it will never happen). At the same time, > tons of stuff depends on Python being "fully" enabled, so shutting it off is > not really an option as well. > > From my experience, if an option needs to be turned on/off most of the time > for things to work, it will be left at the most convenient setting always, so > there really is no value in having the option in the first place. > > From what I have read so far, the only "real" solution would be to move to a > truly "sandboxable"/embeddable scripting language such as LUA, which is not > going to happen or to keep running with the existing model of trusting > everybody not to screw around with Python scripts. > > All other solution that I have seen place an unmanageable burden on the user > and usually require a central controlling entity (i.e. signed vs. unsigned > code having access to restricted functions such as I/O). > > We should keep this in perspective though. Most other 3D packages currently > allow "dangerous" scripting too, so we don't really behave any worse by > allowing scripts in the current setting than any other solution. Which is not > to say that we shouldn't try to be "better" than the other packages on the > long run... > > Ultimately, I would suggest to abandon Python for a truly embedded scripting > solution (i.e. LUA), but that would be a massive change with a huge impact... > maybe worth a thought for Blender 3.0. no need for lua. python is the much nicer language. :p there is pypy which supports sandboxing and which also gets cpython api compatible at the moment. http://morepypy.blogspot.com/2010/04/using-cpython-extension-modules-with.html in 2 years or so (once pypy is more mature and python 3 compatible) it should be no big problem to replace cpython with pypy. as another benefit pypy will be much faster than cpython due to its jit compiler. > > Cheers > > Remo > >> So the scenario here as I see it is: people who don't know about this >> leave the loading of scripts off (and are safe from the evil blender >> hackers out there), next people start having the problems related to >> this setting and due to it being unusable in production they find out >> how to disable it everywhere and then they are right where everything >> started, except from time to time someone forgets to set the flag on >> and gets a nice headache while wondering why this feature exists in >> the first place >> >> > added -Y option to enable script execution, this means render nodes >> > don't need to have .B25.blend's >> > >> > eg. >> > ./blender.bin -b -Y myblend.blend -a >> > >> >> I have a history of lost work and time with this so called security >> >> features where blender decides to turn off drivers and ignore script links >> >> and so on and you don't notice it until you have worked on a faulty >> >> rig/scene for a long time or you have rendered some heavy frames and have >> >> to >> >> do it all over again. In 2.5 since the inclusion of the "trusted source" >> >> option this has done nothing but cause problems everywhere from teaching >> >> to >> >> every day jobs; students load rigs that don't work and naturally they do >> >> not >> >> know the difference, lost time with clients that in order to review a rig >> >> had to turn on the load py scripts option and they didn't knew about it so >> >> we all loose time, etc. >> >> >> >> Today I sent a render to the farm and when it finished the character was >> >> all wrong.. so I spent a long time changing the .B25.blend files on all 17 >> >> machines (boot with X session, change preference, reboot again). After all >> >> this I launch the render again and when it finished the problem is still >> >> there. It so happens that rendering from command line ignores the >> >> .B25.blend >> >> file... so not good. I had to export animation as MDD point cache and >> >> import >> >> back as RVKs in order to workaround the missing drivers >> >> >> >> http://www.pasteall.org/12745 >> >> >> >> So my point of view here is: stop playing around with my scene *please*, >> >> it's hard enough to get things working for blender to decide to break some >> >> random part. And this is the point of view of someone with 8 years of >> >> using >> >> blender almost every day, imagine someone new trying to figure out this >> >> problems? > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
horace grant wrote: > no need for lua. python is the much nicer language. :p there is pypy > which supports sandboxing and which also gets cpython api compatible > at the moment. > > http://morepypy.blogspot.com/2010/04/using-cpython-extension-modules-with.html > > in 2 years or so (once pypy is more mature and python 3 compatible) it > should be no big problem to replace cpython with pypy. as another > benefit pypy will be much faster than cpython due to its jit compiler. > Whether Python is or isn't a nicer language depends on your point of view, so I won't debate that. However, the "sand-boxing" as presented in PyPy is very crude and will do nothing to fix the issues with Python in Blender. The major problem with Python in Blender is not that it can access files "in general" (as that is a REQUIREMENT of import / export scripts for example) but that I can access EVERYTHING Python can from every execution context. That is, I might only want Python to have access to other elements in the scene (say for a rig or controlling a particle simulation) but, so long as Python can access files (which, as I said, is *required*) everything executing Python code can. In Lua, AngelScript, Falcon, TinyScheme, etc it is possible to only expose to the execution context that which you want it to have access to. If you don't want it to read/write files - don't give it the necessary modules/functions. This is not possible in Python (everything is accessible everywhere) and the sand-boxing in PyPy is an "all or nothing" affair. Either you can access the file system or you cannot. No way to only restrict access in only some scripts (say those included in the untrusted .blend file) and not others (those installed by the end-user in the .blender/scripts directory). Not to mention the performance issues with the method PyPy users (dual processes - with all "sand-boxed" data needing to be marshalled between the Blender/Python process and it's sand-boxed proxy). Sorry, Python is designed in such a way as to make securing it an unlikely scenario. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
On Wed, Apr 28, 2010 at 4:06 PM, Benjamin Tolputt wrote: > horace grant wrote: >> no need for lua. python is the much nicer language. :p there is pypy >> which supports sandboxing and which also gets cpython api compatible >> at the moment. >> >> http://morepypy.blogspot.com/2010/04/using-cpython-extension-modules-with.html >> >> in 2 years or so (once pypy is more mature and python 3 compatible) it >> should be no big problem to replace cpython with pypy. as another >> benefit pypy will be much faster than cpython due to its jit compiler. >> > > Whether Python is or isn't a nicer language depends on your point of > view, so I won't debate that. yes, you are right, but i (and i am sure many others too) would really pity if python got removed from blender. if that really needs to happen then it would be better in my opinion to use the language agnostic mono instead of something like lua. i think mono has sandboxing features too. > > However, the "sand-boxing" as presented in PyPy is very crude and will > do nothing to fix the issues with Python in Blender. The major problem > with Python in Blender is not that it can access files "in general" (as > that is a REQUIREMENT of import / export scripts for example) but that I > can access EVERYTHING Python can from every execution context. That is, > I might only want Python to have access to other elements in the scene > (say for a rig or controlling a particle simulation) but, so long as > Python can access files (which, as I said, is *required*) everything > executing Python code can. > > In Lua, AngelScript, Falcon, TinyScheme, etc it is possible to only > expose to the execution context that which you want it to have access > to. If you don't want it to read/write files - don't give it the > necessary modules/functions. This is not possible in Python (everything > is accessible everywhere) and the sand-boxing in PyPy is an "all or > nothing" affair. Either you can access the file system or you cannot. No > way to only restrict access in only some scripts (say those included in > the untrusted .blend file) and not others (those installed by the > end-user in the .blender/scripts directory). Not to mention the > performance issues with the method PyPy users (dual processes - with all > "sand-boxed" data needing to be marshalled between the Blender/Python > process and it's sand-boxed proxy). > > Sorry, Python is designed in such a way as to make securing it an > unlikely scenario. maybe blender developers could contact the pypy developers and discuss this whole thing? i am sure a solution can be found. pypy still is in development and nothing is final. > ___ > 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
Re: [Bf-committers] "Security" gets in the way
I probably should have said "replace Python with some other scripting language". LUA was just an example and this really shouldn't end up being a discussion about what other language this should be but rather on what the overall course of action should/will be. I'm sure that there are many option, LUA just came to my mind first, because I use it in World of Warcraft *grin* and they have exactly the same issues (secure vs. insecure script, context related rights, ...). Cheers Remo > -Original Message- > From: bf-committers-boun...@blender.org [mailto:bf-committers- > boun...@blender.org] On Behalf Of horace grant > Sent: Mittwoch, 28. April 2010 4:57 > To: bf-blender developers > Subject: Re: [Bf-committers] "Security" gets in the way > > On Wed, Apr 28, 2010 at 4:06 PM, Benjamin Tolputt > wrote: > > horace grant wrote: > >> no need for lua. python is the much nicer language. :p there is pypy > >> which supports sandboxing and which also gets cpython api compatible > >> at the moment. > >> > >> http://morepypy.blogspot.com/2010/04/using-cpython-extension- > modules-with.html > >> > >> in 2 years or so (once pypy is more mature and python 3 compatible) > it > >> should be no big problem to replace cpython with pypy. as another > >> benefit pypy will be much faster than cpython due to its jit > compiler. > >> > > > > Whether Python is or isn't a nicer language depends on your point of > > view, so I won't debate that. > > > > yes, you are right, but i (and i am sure many others too) would really > pity if python got removed from blender. if that really needs to > happen then it would be better in my opinion to use the language > agnostic mono instead of something like lua. i think mono has > sandboxing features too. > > > > > > > However, the "sand-boxing" as presented in PyPy is very crude and > will > > do nothing to fix the issues with Python in Blender. The major > problem > > with Python in Blender is not that it can access files "in general" > (as > > that is a REQUIREMENT of import / export scripts for example) but > that I > > can access EVERYTHING Python can from every execution context. That > is, > > I might only want Python to have access to other elements in the > scene > > (say for a rig or controlling a particle simulation) but, so long as > > Python can access files (which, as I said, is *required*) everything > > executing Python code can. > > > > In Lua, AngelScript, Falcon, TinyScheme, etc it is possible to only > > expose to the execution context that which you want it to have access > > to. If you don't want it to read/write files - don't give it the > > necessary modules/functions. This is not possible in Python > (everything > > is accessible everywhere) and the sand-boxing in PyPy is an "all or > > nothing" affair. Either you can access the file system or you cannot. > No > > way to only restrict access in only some scripts (say those included > in > > the untrusted .blend file) and not others (those installed by the > > end-user in the .blender/scripts directory). Not to mention the > > performance issues with the method PyPy users (dual processes - with > all > > "sand-boxed" data needing to be marshalled between the Blender/Python > > process and it's sand-boxed proxy). > > > > Sorry, Python is designed in such a way as to make securing it an > > unlikely scenario. > > > > maybe blender developers could contact the pypy developers and discuss > this whole thing? i am sure a solution can be found. pypy still is in > development and nothing is final. > > > > > ___ > > 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
Re: [Bf-committers] "Security" gets in the way
2010/4/28 Remo Pini > I probably should have said "replace Python with some other scripting > language". LUA was just an example and this really shouldn't end up > being a discussion about what other language this should be but rather > on what the overall course of action should/will be. I'm sure that there > are many option, LUA just came to my mind first, because I use it in > World of Warcraft *grin* and they have exactly the same issues (secure > vs. insecure script, context related rights, ...). > > In this case I would say: how many problems have come up related to security? and you're talking on changing Python because of that. I know it might be something we need to discuss for the future but for now it's not a big problem as far as I know. As someone said, if somebody wants to dirty-hack something, he/she will find the way, that doesn't mean we won't care on security but we cannot make it 100% secure as well. I don't really think that we are moving from Python any time soon. Python has been doing a great job and is deeply embedded in Blender. I think talking on this is not even fair with all the great job as for example ideasman has been doing the last years with the Python API. I would suggest then to be focused on a Python solution. regards, -idesisnery > Cheers > > Remo > > > -Original Message- > > From: bf-committers-boun...@blender.org [mailto:bf-committers- > > boun...@blender.org] On Behalf Of horace grant > > Sent: Mittwoch, 28. April 2010 4:57 > > To: bf-blender developers > > Subject: Re: [Bf-committers] "Security" gets in the way > > > > On Wed, Apr 28, 2010 at 4:06 PM, Benjamin Tolputt > > wrote: > > > horace grant wrote: > > >> no need for lua. python is the much nicer language. :p there is > pypy > > >> which supports sandboxing and which also gets cpython api > compatible > > >> at the moment. > > >> > > >> http://morepypy.blogspot.com/2010/04/using-cpython-extension- > > modules-with.html > > >> > > >> in 2 years or so (once pypy is more mature and python 3 compatible) > > it > > >> should be no big problem to replace cpython with pypy. as another > > >> benefit pypy will be much faster than cpython due to its jit > > compiler. > > >> > > > > > > Whether Python is or isn't a nicer language depends on your point of > > > view, so I won't debate that. > > > > > > > > yes, you are right, but i (and i am sure many others too) would really > > pity if python got removed from blender. if that really needs to > > happen then it would be better in my opinion to use the language > > agnostic mono instead of something like lua. i think mono has > > sandboxing features too. > > > > > > > > > > > > However, the "sand-boxing" as presented in PyPy is very crude and > > will > > > do nothing to fix the issues with Python in Blender. The major > > problem > > > with Python in Blender is not that it can access files "in general" > > (as > > > that is a REQUIREMENT of import / export scripts for example) but > > that I > > > can access EVERYTHING Python can from every execution context. That > > is, > > > I might only want Python to have access to other elements in the > > scene > > > (say for a rig or controlling a particle simulation) but, so long as > > > Python can access files (which, as I said, is *required*) everything > > > executing Python code can. > > > > > > In Lua, AngelScript, Falcon, TinyScheme, etc it is possible to only > > > expose to the execution context that which you want it to have > access > > > to. If you don't want it to read/write files - don't give it the > > > necessary modules/functions. This is not possible in Python > > (everything > > > is accessible everywhere) and the sand-boxing in PyPy is an "all or > > > nothing" affair. Either you can access the file system or you > cannot. > > No > > > way to only restrict access in only some scripts (say those included > > in > > > the untrusted .blend file) and not others (those installed by the > > > end-user in the .blender/scripts directory). Not to mention the > > > performance issues with the method PyPy users (dual processes - with > > all > > > "sand-boxed" data needing to be marshalled between the > Blender/Python > > > process and it's sand-boxed proxy). > > > &g
Re: [Bf-committers] "Security" gets in the way
What ?! how come the discussion started with "current blender defaults are getting in the way with production" which I totally agree and switched to "Let's replace Python with something else" ??? I'm sure there must be a clever way to solve this or maybe this "security problem" Regards malefico. > 2010/4/28 Remo Pini > >> I probably should have said "replace Python with some other scripting >> language". LUA was just an example and this really shouldn't end up >> being a discussion about what other language this should be but rather >> on what the overall course of action should/will be. I'm sure that there >> are many option, LUA just came to my mind first, because I use it in >> World of Warcraft *grin* and they have exactly the same issues (secure >> vs. insecure script, context related rights, ...). >> >> > In this case I would say: how many problems have come up related to > security? and you're talking on changing Python because of that. I know it > might be something we need to discuss for the future but for now it's not > a > big problem as far as I know. As someone said, if somebody wants to > dirty-hack something, he/she will find the way, that doesn't mean we won't > care on security but we cannot make it 100% secure as well. > > I don't really think that we are moving from Python any time soon. Python > has been doing a great job and is deeply embedded in Blender. I think > talking on this is not even fair with all the great job as for example > ideasman has been doing the last years with the Python API. > > I would suggest then to be focused on a Python solution. > > regards, > > -idesisnery > > > >> Cheers >> >> Remo >> >> > -Original Message----- >> > From: bf-committers-boun...@blender.org [mailto:bf-committers- >> > boun...@blender.org] On Behalf Of horace grant >> > Sent: Mittwoch, 28. April 2010 4:57 >> > To: bf-blender developers >> > Subject: Re: [Bf-committers] "Security" gets in the way >> > >> > On Wed, Apr 28, 2010 at 4:06 PM, Benjamin Tolputt >> > wrote: >> > > horace grant wrote: >> > >> no need for lua. python is the much nicer language. :p there is >> pypy >> > >> which supports sandboxing and which also gets cpython api >> compatible >> > >> at the moment. >> > >> >> > >> http://morepypy.blogspot.com/2010/04/using-cpython-extension- >> > modules-with.html >> > >> >> > >> in 2 years or so (once pypy is more mature and python 3 compatible) >> > it >> > >> should be no big problem to replace cpython with pypy. as another >> > >> benefit pypy will be much faster than cpython due to its jit >> > compiler. >> > >> >> > > >> > > Whether Python is or isn't a nicer language depends on your point of >> > > view, so I won't debate that. >> > >> > >> > >> > yes, you are right, but i (and i am sure many others too) would really >> > pity if python got removed from blender. if that really needs to >> > happen then it would be better in my opinion to use the language >> > agnostic mono instead of something like lua. i think mono has >> > sandboxing features too. >> > >> > >> > >> > > >> > > However, the "sand-boxing" as presented in PyPy is very crude and >> > will >> > > do nothing to fix the issues with Python in Blender. The major >> > problem >> > > with Python in Blender is not that it can access files "in general" >> > (as >> > > that is a REQUIREMENT of import / export scripts for example) but >> > that I >> > > can access EVERYTHING Python can from every execution context. That >> > is, >> > > I might only want Python to have access to other elements in the >> > scene >> > > (say for a rig or controlling a particle simulation) but, so long as >> > > Python can access files (which, as I said, is *required*) everything >> > > executing Python code can. >> > > >> > > In Lua, AngelScript, Falcon, TinyScheme, etc it is possible to only >> > > expose to the execution context that which you want it to have >> access >> > > to. If you don't want it to read/write files - don't give it the >> > > necessary modules/functions. This is not possi
Re: [Bf-committers] "Security" gets in the way
+1 Dropping support for Python is going to be hard to accept for many. -it is extremely useful and rich -very easy/user friendly language -closest to 'industry standard' for scripting languages, common in other cg packages -heavily and well integrated into blender 2.5 -ppl have invested lots of effort learning it -ppl have invested lots of effort migrating to the new api -Campbell is solving the security vs. usability issues, people who want to run 'secure but less capable' will be able to, most people in production settings will be running 'more capable but less secure' , however, these people aren't usually running outside files. On Wed, 2010-04-28 at 13:31 -0300, malef...@licuadorastudio.com wrote: > What ?! how come the discussion started with "current blender defaults are > getting in the way with production" which I totally agree and switched to > "Let's replace Python with something else" ??? > > I'm sure there must be a clever way to solve this or maybe this "security > problem" > > Regards > > malefico. > > > > 2010/4/28 Remo Pini > > > >> I probably should have said "replace Python with some other scripting > >> language". LUA was just an example and this really shouldn't end up > >> being a discussion about what other language this should be but rather > >> on what the overall course of action should/will be. I'm sure that there > >> are many option, LUA just came to my mind first, because I use it in > >> World of Warcraft *grin* and they have exactly the same issues (secure > >> vs. insecure script, context related rights, ...). > >> > >> > > In this case I would say: how many problems have come up related to > > security? and you're talking on changing Python because of that. I know it > > might be something we need to discuss for the future but for now it's not > > a > > big problem as far as I know. As someone said, if somebody wants to > > dirty-hack something, he/she will find the way, that doesn't mean we won't > > care on security but we cannot make it 100% secure as well. > > > > I don't really think that we are moving from Python any time soon. Python > > has been doing a great job and is deeply embedded in Blender. I think > > talking on this is not even fair with all the great job as for example > > ideasman has been doing the last years with the Python API. > > > > I would suggest then to be focused on a Python solution. > > > > regards, > > > > -idesisnery > > > > > > > >> Cheers > >> > >> Remo > >> > >> > -Original Message- > >> > From: bf-committers-boun...@blender.org [mailto:bf-committers- > >> > boun...@blender.org] On Behalf Of horace grant > >> > Sent: Mittwoch, 28. April 2010 4:57 > >> > To: bf-blender developers > >> > Subject: Re: [Bf-committers] "Security" gets in the way > >> > > >> > On Wed, Apr 28, 2010 at 4:06 PM, Benjamin Tolputt > >> > wrote: > >> > > horace grant wrote: > >> > >> no need for lua. python is the much nicer language. :p there is > >> pypy > >> > >> which supports sandboxing and which also gets cpython api > >> compatible > >> > >> at the moment. > >> > >> > >> > >> http://morepypy.blogspot.com/2010/04/using-cpython-extension- > >> > modules-with.html > >> > >> > >> > >> in 2 years or so (once pypy is more mature and python 3 compatible) > >> > it > >> > >> should be no big problem to replace cpython with pypy. as another > >> > >> benefit pypy will be much faster than cpython due to its jit > >> > compiler. > >> > >> > >> > > > >> > > Whether Python is or isn't a nicer language depends on your point of > >> > > view, so I won't debate that. > >> > > >> > > >> > > >> > yes, you are right, but i (and i am sure many others too) would really > >> > pity if python got removed from blender. if that really needs to > >> > happen then it would be better in my opinion to use the language > >> > agnostic mono instead of something like lua. i think mono has > >> > sandboxing features too. > >> > > >> > > >> > > >> > > > >> > > However, the "sand-bo
Re: [Bf-committers] "Security" gets in the way
I hope I'm wrong and is something I have missed from the "Security" discussion but is leading to dangerous thougths Dropping python?!?!?! Python support has being one of the best steps Blender has ever made, even before the industry standard packages start considering python (when each one implement their own scripting language leading to a migration chaos among them) I think dropping python is not an option, is a suicide ;) and is definatelly more harming than all the possible threats that is suppose to solve. -1 ad infinitum :) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
I'm looking the Blender as a game creator, not just a 3D tool.A game creator tool must be secure. Just my 2 cents Makslanehttp://game-editor.com _ Mude seu visual no Messenger e divirta-se com seus amigos online. Clique e veja como http://ilm.windowslive.com.br/?ocid=ILM:ILM:Hotmail:Tagline:1x1:Tagline ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
On Wed, Apr 28, 2010 at 10:52 PM, Makslane Rodrigues wrote: > > I'm looking the Blender as a game creator, not just a 3D tool.A game creator > tool must be secure. why must a game creator be secure? for the webplugin security of course would be important but for standalone games it doesn't matter at all. the blender game engine isn't more insecure than any other game engine. ... and it doesn't look like there ever will be a working webplugin again for blender. the future on the web isn't plugins anyway but more likely stuff like webgl... > > Just my 2 cents > Makslanehttp://game-editor.com > _ > Mude seu visual no Messenger e divirta-se com seus amigos online. Clique e > veja como > http://ilm.windowslive.com.br/?ocid=ILM:ILM:Hotmail:Tagline:1x1:Tagline > ___ > 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
Re: [Bf-committers] "Security" gets in the way
On Thu, Apr 29, 2010 at 2:31 AM, wrote: > What ?! how come the discussion started with "current blender defaults are > getting in the way with production" which I totally agree and switched to > "Let's replace Python with something else" ??? Yes, this is getting silly, and I think is representative of the problem. I can see two major perspectives here: a) those from an IT background, where security is very important and security is often a number one priority and b) those who use blender in production, where having a functional 3d application is a number one priority. The fact that people are even suggesting to drop Python is an example of this - placing security in the sense of protecting some contingent of users from themselves, as having higher importance than the pain of completely re-doing Blender's main scripting language which is working very well, that hundreds if not thousands of users depend on, have spent years learning, and which is the standard language of the 3D industry. It just shows how wide the disconnect is. Clearly I don't think this mindset should be driving a discussion that has clear, practical and costly implications for the people that are actually using Blender. The very big problem now is that Blender is not functional by default - very important parts of it do not work after you install it. Your own files *don't work*. This is a very stupid situation to be in, and needs to be changed. Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
> The very big problem now is that Blender is not functional by default > - very important parts of it do not work after you install it. Your > own files *don't work*. This is a very stupid situation to be in, and > needs to be changed. Well said. ~ C ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
Sorry, I mean network games must use a secure game engine. > Date: Wed, 28 Apr 2010 23:28:53 +0200 > From: horac...@gmail.com > To: bf-committers@blender.org > Subject: Re: [Bf-committers] "Security" gets in the way > > On Wed, Apr 28, 2010 at 10:52 PM, Makslane Rodrigues > wrote: > > > > I'm looking the Blender as a game creator, not just a 3D tool.A game > > creator tool must be secure. > > > why must a game creator be secure? for the webplugin security of > course would be important but for standalone games it doesn't matter > at all. the blender game engine isn't more insecure than any other > game engine. > > ... and it doesn't look like there ever will be a working webplugin > again for blender. the future on the web isn't plugins anyway but more > likely stuff like webgl... > > > > > > Just my 2 cents > > Makslanehttp://game-editor.com > > _ > > Mude seu visual no Messenger e divirta-se com seus amigos online. Clique e > > veja como > > http://ilm.windowslive.com.br/?ocid=ILM:ILM:Hotmail:Tagline:1x1:Tagline > > ___ > > 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 _ O Internet Explorer 8 te dá dicas de como navegar mais seguro. Clique para ler todas. http://www.microsoft.com/brasil/windows/internet-explorer/?WT.mc_id=1500 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
My suggestion is that for those who are deeply concerned about the security issue is to investigate how to switch to using pypy as an option. It is fully sandboxable etc. Those who need 'security over usability' can have it. It looks like performance is approaching CPython for many cases and once all of the modules are ported over it can be investigated as a default. LetterRip ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
Blender isn't the only 3d app to use python as embedded language. I wonder how Maya and Houdini deal with these kinds of problems? And not only 3d packages encounter such issues - Google App Engine for example restricts usage of some python modules. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
> Blender isn't the only 3d app to use python as embedded language. I > wonder how Maya and Houdini deal with these kinds of problems? And not > only 3d packages encounter such issues - Google App Engine for example > restricts usage of some python modules. The simple answer is: they don't. If Maya tried to add security settings to files you can bet your own child the uproar would be heard into space, and they'd roll back the change pretty quickly. The same goes for all other packages I've used which implement Python. ~ C ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
Why do we need these "security" features anyway? It's not like there aren't tons of exploits that could be taken advantage off anyway. Blender is a producton 3d app, not a web browser. Joe On Thu, Apr 29, 2010 at 2:09 AM, Charles Wardlaw wrote: >> Blender isn't the only 3d app to use python as embedded language. I >> wonder how Maya and Houdini deal with these kinds of problems? And not >> only 3d packages encounter such issues - Google App Engine for example >> restricts usage of some python modules. > > The simple answer is: they don't. If Maya tried to add security settings to > files you can bet your own child the uproar would be heard into space, and > they'd roll back the change pretty quickly. > > The same goes for all other packages I've used which implement Python. > ~ C > > ___ > 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
Re: [Bf-committers] "Security" gets in the way
joe, I believe, it's possible write a blender python script that will read your private data and send it to author's email and do all sorts of other evil stuff. And if you have "Auto-run scripts" turned, all it takes is a download a blend file, run it and that's it. On Thu, Apr 29, 2010 at 4:21 AM, joe wrote: > Why do we need these "security" features anyway? It's not like there > aren't tons of exploits that could be taken advantage off anyway. > Blender is a producton 3d app, not a web browser. > > Joe > > On Thu, Apr 29, 2010 at 2:09 AM, Charles Wardlaw > wrote: >>> Blender isn't the only 3d app to use python as embedded language. I >>> wonder how Maya and Houdini deal with these kinds of problems? And not >>> only 3d packages encounter such issues - Google App Engine for example >>> restricts usage of some python modules. >> >> The simple answer is: they don't. If Maya tried to add security settings to >> files you can bet your own child the uproar would be heard into space, and >> they'd roll back the change pretty quickly. >> >> The same goes for all other packages I've used which implement Python. >> ~ C >> >> ___ >> 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
Re: [Bf-committers] "Security" gets in the way
Charles Wardlaw wrote: > The simple answer is: they don't. If Maya tried to add security settings to > files you can bet your own child the uproar would be heard into space, and > they'd roll back the change pretty quickly. > According to the Maya documentation, there is a check-box that allows you to disable the execution of "script nodes" when opening the file. This would indeed be a "security measure" available and there has been no uproar on it that I've heard of. > The same goes for all other packages I've used which implement Python. > See my earlier email on HOW Python is used in these applications as compared to Blender. Maya indeed uses Python in it's expressions(with the explicit capability of turning them off on open) like Blender does. The other "heavy hitter" applications do not. Their use of Python is in the construction of plugins from script - not in the embedding of Python in expressions used in rigs. joe wrote: > Why do we need these "security" features anyway? It's not like there > aren't tons of exploits that could be taken advantage off anyway. > Blender is a producton 3d app, not a web browser. > Because Blender is a free modelling, animation, rendering application made available to all people wanting to get their hands dirty in 3D graphics. It is not just production studios that use it, but tens of thousands of people that wish they could be in graphics production. Some of them are working realistically towards that goal (training themselves and putting together better & more complex scenes/animations) and some are just playing at the shallow end of the pool playing with rigs and scripts they download online (alot like the Renderosity crowd of Poser users). Overall though, a fair proportion of these users (that significantly outnumber professional users) will have no concept if what a production environment IS, let alone any security implications therein. Provided Blender continues to get more popular (and I don't see any reason why not, I've got pro artists hanging out for the "easier to use Blender 2.5"); this means more & more casual users. As this casual user base grows, it becomes a more inviting target for malware authors. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
Sorry if this is a repost - I sent this hours ago and it never turned up in my inbox (unlike others I sent more recently). Ignore this if the mailing list already has a copy. Note that I am replying to all of last night's posts - Matt's is just the last in the list & he hits most bases I want to cover. Matt Ebb wrote: >> What ?! how come the discussion started with "current blender defaults are >> getting in the way with production" which I totally agree and switched to >> "Let's replace Python with something else" ??? > > Yes, this is getting silly, and I think is representative of the problem. > To answer the first question, the reason "replacing Python" comes up in the security context is because the source of the security problem is Python's inability to restrict access to built-in functionality depending on context. To fix this security hole (and there is no debate now it IS a security hole) the effort can be spent on one of two things: * Fixing Python so it can have it's functionality limited as & when required * Remove Python from Blender & replacing it with an alternate scripting solution. Regardless of whether people like the choices or not - that is the reality of the situation. Either Python changes or Blender does, but for security to be obtained you cannot have both. The only way out of making this problematic choice (in the end) is to ignore security completely. The concept that debate is silly because some people don't like the fact the choices have been limited by prior decisions in Blender's history is, quite frankly, *insulting*. Security is ALWAYS a trade-off, especially when it comes to being able to run arbitrary script embedded in a "document" or scene file. Look at Word macros and the worms that resulted from that. No-one argues that the macros were useful, anymore than people argued the usefulness of ActiveX web add-ons or the fact that not having a password is easier than having to enter one all the time. Regardless of how skilled & intelligent people are in their area of expertise, a good majority of them are unaware and simply don't care about security implications until such time as it wipes their hard-drive or kills their Internet connection due to spam activity overload. This does not make it any less important a subject for consideration. Seat belts too are a pain until the one time they save your life. > I can see two major perspectives here: a) those from an IT background, > where security is very important and security is often a number one > priority and b) those who use blender in production, where having a > functional 3d application is a number one priority. > This is a false choice that unfairly maligns those on the side of security as "theoretical IT types" as opposed to the "practical Blender users". A more accurate description, without generalising the reasons WHY people are for/against security is simply that there are those that desire security in Blender and those that don't particularly care. Those that want security consider the trade-offs involved (some more drastic than others) whereas those that don't particularly care see ANY trade-off as a negative. That said, a trade-off that results in unworkable files ALL THE TIME as is being suggested by Matt is not a viable one. Especially given the fact that the security issue is not resolved because to make use of any reasonably complex rig nowadays, you need to enable Blender. Meaning that to even try out that cool rig from Artist X's website, you need to disable security... which defeats the purpose of having it in the first place. I cannot think of ANY rig that needs access to my hard-drive to work yet almost EVERY rig worth downloading and looking at requires scripted expressions which, in turn, gives it access to my hard drive. The all or nothing approach is not a reasonable trade-off, even for this "IT background" end-user who wants security. > The fact that people are even suggesting to drop Python is an example > of this - placing security in the sense of protecting some contingent > of users from themselves, as having higher importance than the pain of > completely re-doing Blender's main scripting language which is working > very well, that hundreds if not thousands of users depend on, have > spent years learning, and which is the standard language of the 3D > industry. It just shows how wide the disconnect is. Clearly I don't > think this mindset should be driving a discussion that has clear, > practical and costly implications for the people that are actually > using Blender. > Quite frankly, being the best open-source / free 3D modelling, rigging, animation, etc program available (and yes, I really do think that - the other open-source/free apps don't come near EVERYTHING Blender can do... even if Wings is much nicer to model in *grin*) means that the "contingent of users" needing protection not from themselves but from malicious developers who count on thei
Re: [Bf-committers] "Security" gets in the way
--- On Wed, 4/28/10, Benjamin Tolputt wrote: > From: Benjamin Tolputt > Subject: Re: [Bf-committers] "Security" gets in the way > To: "bf-blender developers" > Received: Wednesday, April 28, 2010, 8:31 PM > Charles Wardlaw wrote: > > The simple answer is: they don't. If Maya tried to add > security settings to files you can bet your own child the > uproar would be heard into space, and they'd roll back the > change pretty quickly. > > > > According to the Maya documentation, there is a check-box > that allows > you to disable the execution of "script nodes" when opening > the file. > This would indeed be a "security measure" available and > there has been > no uproar on it that I've heard of. Because it's off by default, which is the opposite of the current state in Blender. You can bet whatever you want that if this was ever turned on by default, autodesk would do the fastest turn around time on a feature ever seen and bring it back off. Moreover, if that only concerns script nodes, my educated guess is that it leaves gaping holes (security theater anyone?). In any case, Blender already has an option to turn on "thrust" when opening files. Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
Hey Guys, Thoughts on security issues. Why can't the devs with the know how, or the ones that desire the challenge and the kudos, take some time and hard code the "most worthy" script functionality into Blender? Many of the scripts seem to fill in the gaping holes in Blender's functionality as compared to the paid programs, anyhow. Python is the common language, that many humans can dabble in and provide prototypical solutions to new functions, but can't the devs who are competent in C take this functionality and incorporate it directly into Blender? Best, AMR Sent from my Verizon Wireless BlackBerry -Original Message- From: Benjamin Tolputt Date: Thu, 29 Apr 2010 11:45:20 To: Benjamin Tolputt; bf-blender developers Subject: Re: [Bf-committers] "Security" gets in the way Sorry if this is a repost - I sent this hours ago and it never turned up in my inbox (unlike others I sent more recently). Ignore this if the mailing list already has a copy. Note that I am replying to all of last night's posts - Matt's is just the last in the list & he hits most bases I want to cover. Matt Ebb wrote: >> What ?! how come the discussion started with "current blender defaults are >> getting in the way with production" which I totally agree and switched to >> "Let's replace Python with something else" ??? > > Yes, this is getting silly, and I think is representative of the problem. > To answer the first question, the reason "replacing Python" comes up in the security context is because the source of the security problem is Python's inability to restrict access to built-in functionality depending on context. To fix this security hole (and there is no debate now it IS a security hole) the effort can be spent on one of two things: * Fixing Python so it can have it's functionality limited as & when required * Remove Python from Blender & replacing it with an alternate scripting solution. Regardless of whether people like the choices or not - that is the reality of the situation. Either Python changes or Blender does, but for security to be obtained you cannot have both. The only way out of making this problematic choice (in the end) is to ignore security completely. The concept that debate is silly because some people don't like the fact the choices have been limited by prior decisions in Blender's history is, quite frankly, *insulting*. Security is ALWAYS a trade-off, especially when it comes to being able to run arbitrary script embedded in a "document" or scene file. Look at Word macros and the worms that resulted from that. No-one argues that the macros were useful, anymore than people argued the usefulness of ActiveX web add-ons or the fact that not having a password is easier than having to enter one all the time. Regardless of how skilled & intelligent people are in their area of expertise, a good majority of them are unaware and simply don't care about security implications until such time as it wipes their hard-drive or kills their Internet connection due to spam activity overload. This does not make it any less important a subject for consideration. Seat belts too are a pain until the one time they save your life. > I can see two major perspectives here: a) those from an IT background, > where security is very important and security is often a number one > priority and b) those who use blender in production, where having a > functional 3d application is a number one priority. > This is a false choice that unfairly maligns those on the side of security as "theoretical IT types" as opposed to the "practical Blender users". A more accurate description, without generalising the reasons WHY people are for/against security is simply that there are those that desire security in Blender and those that don't particularly care. Those that want security consider the trade-offs involved (some more drastic than others) whereas those that don't particularly care see ANY trade-off as a negative. That said, a trade-off that results in unworkable files ALL THE TIME as is being suggested by Matt is not a viable one. Especially given the fact that the security issue is not resolved because to make use of any reasonably complex rig nowadays, you need to enable Blender. Meaning that to even try out that cool rig from Artist X's website, you need to disable security... which defeats the purpose of having it in the first place. I cannot think of ANY rig that needs access to my hard-drive to work yet almost EVERY rig worth downloading and looking at requires scripted expressions which, in turn, gives it access to my hard drive. The all or nothing approach is not a reasonable trade-off, even for this "IT background" end-user who wants security. > The fact
Re: [Bf-committers] "Security" gets in the way
> According to the Maya documentation, there is a check-box that allows > you to disable the execution of "script nodes" when opening the file. > This would indeed be a "security measure" available and there has been > no uproar on it that I've heard of. It's actually not a security measure, although I can see why it could be viewed as such. That feature is in there because sometimes Maya can save out files it cannot read back in, and often the only way to get at your data in order to salvage some of it is to disable scripts and expressions. I'm using that feature at work to debug some inherited assets because when I load them up straight Maya likes to hang. But there's a difference between that and what Blender's currently doing: that "security" feature is opt-in. Blender's is not, but in my opinion should be. And as an aside, that feature in Maya can be gotten around with deferred execution and a hack in a Maya ASCII file. Again: not security, but a debugging tool. I'm surprised that nobody has mentioned the simple solution of disallowing automatic scripts and scripted constraints from accessing the os and sys modules (perhaps limiting imports to only bpy). It'd be easy enough to implement as a security measure by just scanning the code or executing the code in a space where those modules were never importable, but wouldn't break rigs. ~ C > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
--- On Wed, 4/28/10, Charles Wardlaw wrote: > I'm surprised that nobody has mentioned the simple solution > of > disallowing automatic scripts and scripted constraints from > accessing > the os and sys modules (perhaps limiting imports to only > bpy). That's because it doesn't work. Anybody that really wants to get around such a block can (and get access to all file read and write functionality). One of the only safe way to sandbox CPython would be to wrap the whole low level Clib and event that most likely would leave some holes (beside being a mammoth task). Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
Hey Guys, Well I only saw a few snippets of this thread and didn't wanna read it completely since the discussion was going pointless with "lets replace python with some other scripting language" . Replacing or restricting sounds completely lame when the whole industry is moving towards python to harness its capabilities :) . +1 for Matt Ebb`s points . Also if security is a concern to many non-production or casual artists then blender developers can provide an option in blender command line which can disable the so called "security" so it doesn't hamper the real production. TDs in production can then make a shell script or batch file that starts blender with that option turned on so it doesn`t cause problems and distribute it in their studio . Its still irritating to do so many stunts in a studio to get it working as excepted . I would rather like to dump that security feature if its a problem :/ . One more idea is to have it disabled by default like maya and other 3d apps and have a tick box in splash screen with bold text "enable security" , . My 2 cents ;) regards shrinidhi -- Ęvęņ ģóđ fąįļş ŧŏ ųŋđęŗşţąņđ å ĥųmąņ ųņţĭļ ĥĭş đęąţĥ http://www.linkedin.com/in/shrinidhi666 http://www.shrinidhi666.wordpress.com http://www.imdb.com/name/nm3025616 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
Charles Wardlaw wrote: > But there's a difference between that and what Blender's currently > doing: that "security" feature is opt-in. Blender's is not, but in my > opinion should be. > Again I come back to the user-base of the applications in question. How many people do you know outside the graphics industry that have Maya installed at home? How many of them have it installed (& hence licensed) on multiple machines? I happen to know, right out of my personal experience, three people that have Blender installed because they wanted to play around - a legal secretary, an arborist, and a housewife who wants to make 3D web-comics (but isn't quite there with the skills yet). I believe that these casual users would make up a significant majority of the downloads of Blender from the primary website. I have no real statistics to back it up, of course, no-one does to the contrary either. Ton could probably tell us how many downloads in total there are and, even assuming everyone downloads it twice for some leeway, I don't think the number of professional users would add up to 20% of that figure. These casual users don't even KNOW what the option would mean and they are the most likely ones to need it. They are not going to "opt-in" to something they don't understand. That said, these people are going to be just as frustrated when they come across the limitations of the opt-in solution as Matt Ebb & Co are. They'll download something off the web because it looks cool and either will disable the option to get it to work (compromising their system) or get ticked off that it doesn't work (which is likely for any armature more complex than a basic reverse foot rig). > I'm surprised that nobody has mentioned the simple solution of > disallowing automatic scripts and scripted constraints from accessing > the os and sys modules (perhaps limiting imports to only bpy). It'd be > easy enough to implement as a security measure by just scanning the > code or executing the code in a space where those modules were never > importable, but wouldn't break rigs. > Because it is not possible. Look at the last security mailing frenzy on this list and I think it was Campbell that showed a few ways around what you suggest. As I have mentioned a couple of times now, Python is designed to allow access to everything from everywhere. If it wasn't an explicit desire when putting together the language, it sure as daylight is a standard feature now and removing it is likely to cause some big problems. Python does not allow a single virtual machine to allow some parts of code to run in a secure, module-limited subset of the execution context (as would be needed to limit rig expressions to secure subsets) whilst allowing other blocks of code to run relatively unsecured (like that required for import / export plugins). It is a language limitation not shared by many other languages, such as Lua, TinyScheme, Falcon & others. The issue is a language limitation which would require major changes to the Python VM code (and alot of testing of the Python modules) to implement... whilst forever needing maintenance by Blender developers as the Python development team has already stated they are not interested in such sandboxing. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
Hello, Sorry, but I couldn’t resist weighing into this debate because I feel I have a fairly unique perspective on this security issue. I am a Blender noob, a long-time developer (25 years but very little with C), but I spend my days as a network administrator for a large-ish network (650 users, 700 computers). So you would naturally think that I would be in the “theoretical IT types” in favor of high security in Blender. But I am not. In fact the only feature I would need is the temporary ability to load an autoexecuting blend without it doing so. Otherwise, I wish for no other prompts, preferences, or nannying. Yes, it is easy to make a python script that steals passwords or deletes your files, just as it is easy to do so in any programming language. The danger potentially lurking in an evil blend file is the same as in any program you could download from the internet. There isn’t any comparison to Word and Excel macro viruses or other types of threat. Blend files just don’t have the same audience, or the ability to quickly propagate. You either need fast self-replication or very fast and wide direct distributions in order keep it from self-limiting and to isolate the writer of the threat from getting caught. Seriously… try to imagine a scenario where you could cause mischief in some way with an autoexecuting Blend that would be long-lasting and leaves you anonymous, and therefore out of jail. Blend file just aren’t traded and shared the way the Word files are. We’ve had the ability to run scripts on load for years and this threat has yet to surface. At my very secure network my uses cannot do anything (with python or anything else) that could wreck the computer they are using because they don’t run with the privileges necessary to do such damage. They are also unable to damage any files but their own, and if they manage that they can just restore them themselves from a snapshot from a few hours earlier. Or they can have me restore their files from a backup. So for me this isn’t a “security hole”, but just what any program can potentially do. You have the weigh the risks and deal with all the possibilities. My users are much more likely to accidentally delete files themselves than have something else do it for them. Just my two cents. Harley Acheson Virtual Dogsbody Info Tech Department Shawnigan Lake School ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
Harley Acheson wrote:
> I am a Blender noob, a long-time developer (25 years but very little with C),
> but I spend my days as a network administrator for a large-ish network (650
> users, 700 computers). So you would naturally think that I would be in the
> “theoretical IT types” in favor of high security in Blender.
> ...
> At my very secure network my uses cannot do anything (with python or anything
> else)
> that could wreck the computer they are using because they don’t run with the
> privileges
> necessary to do such damage. They are also unable to damage any files but
> their own,
> and if they manage that they can just restore them themselves from a snapshot
> from a few
> hours earlier. Or they can have me restore their files from a backup.
>
Actually, from that I would think you'd be one of those calling for
Blender to have an option on installation to ignore security. After all,
you are in a network situation someone with knowledge of security has
put time & effort into locking down machines & their capabilities.
You've obviously got a decent backup system in place and would be
knowledgeable in the risks / exploits you'd need to guard the network
against.
In fact, aside from the fact I am a developer (HelpDesk & network admin
was not my thing), you are very similar to myself in what I know & how I
would go about securing my own computing resources. The environment you
describe sounds like a well regulated production studio network too:
highly networked, strict & frequent backups, and with user accounts
designed to be as fool proof as the sys-admin guy can make them.
This is the PERFECT environment for allowing unfettered control over
Python as damage will be restricted and the worst that can happen is
files the user has access to will be sent out into the Internet to be
picked up by whoever compromised their system.
Unfortunately, most people downloading and playing with Blender will NOT
be in such an environment. They'll be user tinkering around with Blender
in an unsecured network, without backups, with a file system fully
accessible to a compromised Blender installation, and (most importantly)
without the knowledge there might be a danger in opening scene file they
downloaded from the web.
> Yes, it is easy to make a python script that steals passwords or deletes your
> files, just
> as it is easy to do so in any programming language. The danger potentially
> lurking in
> an evil blend file is the same as in any program you could download from the
> internet.
>
While stealing your passwords and deleting your files is bad, the most
common use of malware at the moment is in the creation of nodes in a
bot-net. These are usually just outlets for spam and participants in
DDOS attacks. You might also lose passwords and/or have your files
deleted, but the commercial success of hacking machines for this purpose
is limited,.
Bot-nets on the other hand are profitable for the criminal organisations
that "sponsor" such malware development. A bot-net can send out millions
of emails from Nigerian Royalty, phallic herbal pharmacies, and banks
seeking verification of your username & password. These ARE profitable
enterprises, as is the use of bot-nets to blackmail gambiling sites &
the like with the threat if DDOS attacks (backed up by taking them
offline for an hour or so first).
Also, in the minds of most end-users "opening" a document (or .blend)
they got off the web is very different to "running" a program they
downloaded. This is reinforced by the fact that one is asked whether
they want to open a file or save it (in Chrome & FireFox) for documents
and only given the choice of saving the file if it has a recognised
application extension. And, for the most part, applications that allow
opening files that might give unauthorised access to the users computer
tend to pop-up a warning of such ("This files has macros which may do X,
Y, & Z. Do you wish to enable them when loading? Yes. No"). Leading me
into...
> There isn’t any comparison to Word and Excel macro viruses or other types of
> threat.
> Blend files just don’t have the same audience, or the ability to quickly
> propagate. You
> either need fast self-replication or very fast and wide direct distributions
> in order keep
> it from self-limiting and to isolate the writer of the threat from getting
> caught.
>
> Seriously… try to imagine a scenario where you could cause mischief in some
> way with
> an autoexecuting Blend that would be long-lasting and leaves you anonymous,
> and
> therefore out of jail. Blend file just aren’t traded and shared the way the
> Word files are.
> We’ve had the ability to run scripts on load for years and this threat has
> yet to surface.
>
Yes, Word & Excel documents are more popular. No debating that... but
claiming that because someone hasn't exploited a security hole yet means
it is not likely to happen is something I find VERY surprising coming
from a network admin.
Re: [Bf-committers] "Security" gets in the way
There are couple of things that can be done to improve the situation:
1) Include a warning message in the splash screen in bold letters
about downloading and opening random .blends and scripts from the
Internet.
2) Create some sort of official content and scripts repository for
Blender with some sort of approving scheme. Maybe create an add-on for
Blender to download and install content approved by community and/or
developers.
So, it boils down to a) educating users about security awareness, b)
creating a network of trust and incidentally making finding and
installing safe content easier.
On Thu, Apr 29, 2010 at 10:23 AM, Benjamin Tolputt
wrote:
> Harley Acheson wrote:
>> I am a Blender noob, a long-time developer (25 years but very little with C),
>> but I spend my days as a network administrator for a large-ish network (650
>> users, 700 computers). So you would naturally think that I would be in the
>> “theoretical IT types” in favor of high security in Blender.
>> ...
>> At my very secure network my uses cannot do anything (with python or
>> anything else)
>> that could wreck the computer they are using because they don’t run with the
>> privileges
>> necessary to do such damage. They are also unable to damage any files but
>> their own,
>> and if they manage that they can just restore them themselves from a
>> snapshot from a few
>> hours earlier. Or they can have me restore their files from a backup.
>>
>
> Actually, from that I would think you'd be one of those calling for
> Blender to have an option on installation to ignore security. After all,
> you are in a network situation someone with knowledge of security has
> put time & effort into locking down machines & their capabilities.
> You've obviously got a decent backup system in place and would be
> knowledgeable in the risks / exploits you'd need to guard the network
> against.
>
> In fact, aside from the fact I am a developer (HelpDesk & network admin
> was not my thing), you are very similar to myself in what I know & how I
> would go about securing my own computing resources. The environment you
> describe sounds like a well regulated production studio network too:
> highly networked, strict & frequent backups, and with user accounts
> designed to be as fool proof as the sys-admin guy can make them.
>
> This is the PERFECT environment for allowing unfettered control over
> Python as damage will be restricted and the worst that can happen is
> files the user has access to will be sent out into the Internet to be
> picked up by whoever compromised their system.
>
> Unfortunately, most people downloading and playing with Blender will NOT
> be in such an environment. They'll be user tinkering around with Blender
> in an unsecured network, without backups, with a file system fully
> accessible to a compromised Blender installation, and (most importantly)
> without the knowledge there might be a danger in opening scene file they
> downloaded from the web.
>
>> Yes, it is easy to make a python script that steals passwords or deletes
>> your files, just
>> as it is easy to do so in any programming language. The danger potentially
>> lurking in
>> an evil blend file is the same as in any program you could download from the
>> internet.
>>
>
> While stealing your passwords and deleting your files is bad, the most
> common use of malware at the moment is in the creation of nodes in a
> bot-net. These are usually just outlets for spam and participants in
> DDOS attacks. You might also lose passwords and/or have your files
> deleted, but the commercial success of hacking machines for this purpose
> is limited,.
>
> Bot-nets on the other hand are profitable for the criminal organisations
> that "sponsor" such malware development. A bot-net can send out millions
> of emails from Nigerian Royalty, phallic herbal pharmacies, and banks
> seeking verification of your username & password. These ARE profitable
> enterprises, as is the use of bot-nets to blackmail gambiling sites &
> the like with the threat if DDOS attacks (backed up by taking them
> offline for an hour or so first).
>
> Also, in the minds of most end-users "opening" a document (or .blend)
> they got off the web is very different to "running" a program they
> downloaded. This is reinforced by the fact that one is asked whether
> they want to open a file or save it (in Chrome & FireFox) for documents
> and only given the choice of saving the file if it has a recognised
> application extension. And, for the most part, applications that allow
> opening files that might give unauthorised access to the users computer
> tend to pop-up a warning of such ("This files has macros which may do X,
> Y, & Z. Do you wish to enable them when loading? Yes. No"). Leading me
> into...
>
>> There isn’t any comparison to Word and Excel macro viruses or other types of
>> threat.
>> Blend files just don’t have the same audience, or the ability to quickly
>> propagate. You
>> either need fast self-replica
Re: [Bf-committers] "Security" gets in the way
Hi all, Maybe somebody's mentioned this, but one compromise could be to add an option at installation time to select for "Heightened security (some functionality disabled)". This could be "recommended for first-time users" but not set as the default. T ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
> Python does not allow a single virtual machine to allow some parts of > code to run in a secure, module-limited subset of the execution context > (as would be needed to limit rig expressions to secure subsets) whilst > allowing other blocks of code to run relatively unsecured (like that > required for import / export plugins). It is a language limitation not > shared by many other languages, such as Lua, TinyScheme, Falcon & > others. The issue is a language limitation which would require major > changes to the Python VM code (and alot of testing of the Python > modules) to implement... whilst forever needing maintenance by Blender > developers as the Python development team has already stated they are > not interested in such sandboxing. So you're telling me I can't modify sys.path to remove the standard Python libraries? I'm not talking about a safe and secure sandboxed VM-- I mean literally remove the functionality. It's just a zip file or a folder or whatever, and there's no reason you can't block access to os and sys by not letting the interpreter see them. I can hear the argument about importers and exporters not working, but you could follow Tony's suggestion about popping up a message that says "This can't be used because of security features" and then allow the user to make a choice about what they want to do. There are ways around any security system. The arguments for this kind of stuff seem to be about protecting the retired grandfathers and soccer moms. Those kind of first-time users don't need OBJ import. Or if people really care about security, move importers and exporters and geometry shaders that write PTC files and anything else requiring disk access into C code to get around that limitation. os and sys are nice to have for certain kinds of directory walking, but they're not necessary for the majority of Blender's functionality. The other option is code introspection-- It's simple enough to read through text and see what's imported before it's even fed to the interpreter. There's no reason that autoloaded scripts couldn't be inspected at file open for dangerous items. I don't think any of the arguments for this security hold water. Sure, there will eventually be .blend viruses, and they'll be scanned for by programs like Avast and filtered out of mail messages and a few users are going to get bitten, badly. But the one thing nobody is saying is that since Blender's open source, it doesn't matter whether or not the user downloads a bad .blend. Users who are likely to get hurt by such problems are just as likely to download a "special custom build with extra functionality!" which has even worse stuff bundled inside. There's already a community notion that if you want to try out the latest and greatest, you go to graphicall. Who makes those builds? How do I know people aren't hacking the C code to steal my password? And if those builds are safe, then the builds at www.whateversite.com by the guy who's been a part of the community for a long time must also be safe, right? I say leave up a message on the download page or put it in the installer that Python is not secure and that by running Blender people may be opening themselves up to attack, or pop up a message if being run interactively. Not that I've ever heard of such attacks on users of embedded Python. ~ C ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
> *Mono*: > On the suggestion of Mono, this is a no-go before it even get's to the > starting block. The components needed to make Mono run are quite large > in size and not guaranteed to be on every machine. Currently Blender > runs just fine by distributing the required Python dependencies along > with it (though it locates existing installations just fine as well). > Doing the same for Mono would blow out the download size of the default > Python by a large factor. i don't think that's true. the unity webplayer comes with mono and mono doesn't take more than 4mb there (and this includes the languages boo and unityscript). python 3.1 takes 2.7mb. i have also read on miguel de icaza's blog that mono's moonlight profile is even smaller and contains all of the important stuff. he recommended it to the unity developers. > *PyPy as a solution:* > The problem with PyPy is that, like the current situation, it is an all > or nothing approach. PyPy will give you the choice of allowing Blender > to access your file system (a requirement for import/export scripts) or > will lock it down. Recall that the problem with Python isn't that it can > allow access to the hard-drive, but that either EVERY Python script & > expression can do it or none of them can. Rigs don't need access to the > network, file systems, operating system features etc; but if we give it > to the import/export scripts - we give it to the rigs. Python's all or > nothing problem is based on the language design & modules developed > around it, not the virtual machine used to execute the code (which is > all PyPy is attempting to change). couldn't you run 2 separate pythons? but that would be the worst case. i really would contact the pypy developers first and get their opinion about it. i follow their mailing list a bit and there seem to be a lot of experiments going on with their sandbox. probably i am wrong but to me it seemed like some people tryed to enable/disable certain features just like it would be needed for blender. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
Again a discussion that turned into a real mess. I don't see the point really. The best security is still your brain and not a button which says "make my computer secure" or whatever. You are downloading lots of different file types every day. Just don't load files from sources you don't trust. It's as simple as that. It's a general problem in the computer world. The danger is here, everywhere. Even the OS itself can kill all your data and do crazy things. There is no 100% security. Make backups on CDs, DVDs, this is the way. The user should start to think and become aware of computers advantages and disatvantages, including security issues. There is no "make my Computer and data secure" button, neither in the OS nor an application. And there won't be any! Thomas Am 29.04.2010 02:41, schrieb Ruslan Merkulov: > joe, I believe, it's possible write a blender python script that will > read your private data and send it to author's email and do all sorts > of other evil stuff. And if you have "Auto-run scripts" turned, all it > takes is a download a blend file, run it and that's it. > > On Thu, Apr 29, 2010 at 4:21 AM, joe wrote: > >> Why do we need these "security" features anyway? It's not like there >> aren't tons of exploits that could be taken advantage off anyway. >> Blender is a producton 3d app, not a web browser. >> >> Joe >> ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
--- On Thu, 4/29/10, Charles Wardlaw wrote:
> So you're telling me I can't modify sys.path to remove the
> standard Python libraries?
File access is part of builtins, you can remove that.
Even if you try, there's a million of sneaky ways to get it back, like the
following:
[t for t in type(1).__class__.__base__.__subclasses__() if hasattr(t,
"write")][0]("/path/to/file", "w").write("my payload")
> I'm not talking about a
> safe and secure sandboxed VM-- I mean literally remove the
> functionality. It's just a zip file or a folder or
> whatever, and there's no reason you can't block access to os
> and sys by not letting the interpreter see them.
os and sys are not required for file access.
Moreover, depending on the platform, they can be built into the interpreter
(not external modules).
> The other option is code introspection-- It's simple enough
> to read through text and see what's imported before it's
> even fed to the interpreter. There's no reason that
> autoloaded scripts couldn't be inspected at file open for
> dangerous items.
Good luck with that.
Even with an import hook, it's possible to go around such a measure.
> I say leave up a message on the download page or put it in
> the installer that Python is not secure and that by running
> Blender people may be opening themselves up to attack, or
> pop up a message if being run interactively. Not that
> I've ever heard of such attacks on users of embedded
> Python.
Sometimes it's not malicious. It could just be a poorly written script that
craps files all over your HD if not run in a certain way.
Martin
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
Charles Wardlaw wrote: > So you're telling me I can't modify sys.path to remove the standard Python > libraries? I'm not talking about a safe and secure sandboxed VM-- I mean > literally remove the functionality. It's just a zip file or a folder or > whatever, and there's no reason you can't block access to os and sys by not > letting the interpreter see them. I can hear the argument about importers > and exporters not working, but you could follow Tony's suggestion about > popping up a message that says "This can't be used because of security > features" and then allow the user to make a choice about what they want to do. > Actually, you answer your own question. You cannot remove the os & sys modules without it affecting other parts of Python. Not only the importser/exporters but other modules built into Python also refer to these module and they would crash. Removing these modules would require testing all other modules for correct behaviour. And it is not just these modules that would be useful to a malware author. there is subprocess, socket, threading, email, io, platform, shutil, and many more that could be used to get access to resources that are not required for rigging/animation purposes in Blender. And this is ignoring the built-in functions that don't require the loading of modules... like the open() function which allows the creation of &/or reading of files so long as you know a valid path. Once you've gone to all that effort of hacking Python to be... well, not Python - why stick with the language? I think the biggest problem is that everyone is looking for an "easy answer" and there simply isn't one. > There are ways around any security system. The arguments for this kind of > stuff seem to be about protecting the retired grandfathers and soccer moms. > This I can agree with you on, the user-base we're looking to help are the soccer moms, retired grandfathers, legal secretaries, and tree loppers... > Those kind of first-time users don't need OBJ import. > ...and then you lose me entirely. Sorry, but until such time as ".blend" is a standard file format, how exactly do you expect people to fill a basic scene? If it's open content, it is almost invariably available in an OBJ format. Collada is picking up speed, but it is not there yet. Hell, The web-comic artist-to-be I talked about in an earlier email gets a majority of her art from Poser props exported as, you guessed it, OBJ files. > Or if people really care about security, move importers and exporters and > geometry shaders that write PTC files and anything else requiring disk access > into C code to get around that limitation. os and sys are nice to have for > certain kinds of directory walking, but they're not necessary for the > majority of Blender's functionality. > This is indeed a possibility, but given that the general environment here seems adverse to anything resembling a large amount of effort to securing Blender (a viable & understandable position); I think this is another "non-starter" solution. Especially when there is no "greasy wheel needing a kick". We're already facing outright hostility to the effort required for a basic "on/off" solution to the problem from core developers. I don't think it is a long bow to draw expecting the "moving all standard import/export plugins to C" idea to be tossed aside almost immediately. > The other option is code introspection-- It's simple enough to read through > text and see what's imported before it's even fed to the interpreter. > There's no reason that autoloaded scripts couldn't be inspected at file open > for dangerous items. > OK, have you actually read Campbell's emails to the list on this? It is *trivial* to hide the real intent of Python code, /especially/ from automated code introspection functionality. Virii make it through the filters designed by multi-million dollar companies *dedicated* to this task. It took Campbell not even a day after reading how two research papers suggested securing Python to find away around it; even if it takes your average malware author four times the amount of time to get around our open-source filter - he'll have it done in under a week tops. > I don't think any of the arguments for this security hold water. Sure, there > will eventually be .blend viruses, and they'll be scanned for by programs > like Avast and filtered out of mail messages and a few users are going to get > bitten, badly. But the one thing nobody is saying is that since Blender's > open source, it doesn't matter whether or not the user downloads a bad > .blend. Users who are likely to get hurt by such problems are just as likely > to download a "special custom build with extra functionality!" which has even > worse stuff bundled inside. There's already a community notion that if you > want to try out the latest and greatest, you go to graphicall. Who makes > those builds? How do I know people aren't hacking the C co
Re: [Bf-committers] "Security" gets in the way
I have to say this to lighten the situation: I guess the end result is that windows is crap, if you need security use linux! lolololol!! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
> File access is part of builtins, you can remove that.
> Even if you try, there's a million of sneaky ways to get it back, like the
> following:
>
> [t for t in type(1).__class__.__base__.__subclasses__() if hasattr(t,
> "write")][0]("/path/to/file", "w").write("my payload")
There're ways around any security measure; even UBISoft's "uncrackable" DRM for
their games was cracked this weekend.
> os and sys are not required for file access.
Bad example, but I hope the point was still made.
> Moreover, depending on the platform, they can be built into the interpreter
> (not external modules).
Aren't all 2.5 versions using an internal Python3.1 distribution that BF
controls? If folks are serious about this, external python in official builds
can be disallowed and the internal Python stack can be nerfed.
> Good luck with that.
> Even with an import hook, it's possible to go around such a measure.
Sure, but again, people could get around most of the suggestions that have come
up in this thread. Trying to catch the broadest attempts at security breaches
is all anyone can really be tasked with. At some point someone is going to
find a way around the security, and there will be issues. It's unavoidable.
> Sometimes it's not malicious. It could just be a poorly written script that
> craps files all over your HD if not run in a certain way.
Which is a very good point, and adds validity to the notion of a central
"trusted scripts" repository. Having a trusted scripts / rigs place online
that new users are pointed towards (instead of long BlenderArtists threads)
would go much further to solving these issues than adding security layers to
the software and inconveniencing long-time power users IMO.
Then again, it needs someone to manage it.
~ C
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
Is time to end up this security discussion: paperware is very beautiful but never leave the planification phase. The pro-security team could work on a prototype that could shut up the rest of us that think this discussion is getting in the way, meanwhile, the rest of us could continue improving blender. regards farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
> And it is not just these modules that would be useful to a malware > author. there is subprocess, socket, threading, email, io, platform, > shutil, and many more that could be used to get access to resources that > are not required for rigging/animation purposes in Blender. And this is > ignoring the built-in functions that don't require the loading of > modules... like the open() function which allows the creation of &/or > reading of files so long as you know a valid path. Once you've gone to > all that effort of hacking Python to be... well, not Python - why stick > with the language? No answer for you. But if people aren't willing to remove that functionality, or limit it globally in the internal interpreter, then there's no way to lock things down. > I think the biggest problem is that everyone is looking for an "easy > answer" and there simply isn't one. Agreed. > ...and then you lose me entirely. Sorry, but until such time as ".blend" > is a standard file format, how exactly do you expect people to fill a > basic scene? If it's open content, it is almost invariably available in > an OBJ format. Collada is picking up speed, but it is not there yet. > Hell, The web-comic artist-to-be I talked about in an earlier email gets > a majority of her art from Poser props exported as, you guessed it, OBJ > files. I think there's a difference between users who want inter-program operation and users who want to do everything inside one software package. Most of the hobbyist Blender users I know (most, not all) do EVERYTHING inside Blender and never round-trip to external software. The web-comic artist you spoke of would not be an entry-level user in my opinion; by the time he's ready to do stuff like that he's also ready to make the decision to unlock the additional functionality and drop the security barrier. But until that point, while he's learning the software and getting to grips with what's possible? No, I don't think he needs an interchange format. > This is indeed a possibility, but given that the general environment > here seems adverse to anything resembling a large amount of effort to > securing Blender (a viable & understandable position); I think this is > another "non-starter" solution. Especially when there is no "greasy > wheel needing a kick". We're already facing outright hostility to the > effort required for a basic "on/off" solution to the problem from core > developers. I don't think it is a long bow to draw expecting the "moving > all standard import/export plugins to C" idea to be tossed aside almost > immediately. Agreed, but if the people interested in security aren't interested in writing C-language "trusted operators" to lock down the system then they must not be that interested in security, right? > OK, have you actually read Campbell's emails to the list on this? It is > *trivial* to hide the real intent of Python code, /especially/ from > automated code introspection functionality. Virii make it through the > filters designed by multi-million dollar companies *dedicated* to this > task. It took Campbell not even a day after reading how two research > papers suggested securing Python to find away around it; even if it > takes your average malware author four times the amount of time to get > around our open-source filter - he'll have it done in under a week tops. Yes, I did read Campbell's mails. But ANYTHING that's done security-wise can be cracked! It's not about trying to lock down the system 100% perfectly -- the only system that's locked down is the one that's unplugged and locked away from humans. And Blender is worse off from the get-go because all discussion about security in it is done on an open forum, and the code is easily perused for holes. I was trying to suggest that a compromise might be reached where a bit of introspection were done. As exploits are discovered you could update the exploit list in Blender to recognize new code strings. No, it won't catch everything, but nothing will. Anyway, retracted. > Again, back to dismissing the problem through characterising anyone not > skilled in computer technology as an idiot. Opening a file in Photoshop > or GIMP does not make make one vulnerable to exploits. Neither does > opening a file in MyPaint, WinAmp, Google SketchUp, or Wings (reading > across a row of shortcuts on my desktop). Opening a potentially > dangerous file in OpenOffice (next row of shortcut icons) explicitly > asks me whether I wish to enable the possibly dangerous scripts. This is > standard behaviour for applications where you view or edit something. > Most applications are built to cater for the fact that end-users > differentiate between "running a program" and "opening a document". > Trying to ignore this does not change the fact. I'm doing nothing of the sort. I myself have been tired and downloaded the wrong thing from the wrong site and ended up with a bricked XP machine more than once. I also once
Re: [Bf-committers] "Security" gets in the way
Raul Fernandez Hernandez wrote: > Is time to end up this security discussion: paperware is very beautiful > but never leave the planification phase. > The pro-security team could work on a prototype that could shut up the > rest of us that think this discussion is getting in the way, meanwhile, > the rest of us could continue improving blender. Are you speaking for the Blender development team or just yourself? Serious question as I'd like to know if the opinion that adding security is not part of "improving Blender" is shared at the top level. After all, if Ton (for example) doesn't want there to be a security option - there simply isn't going to be one as it will never get into trunk. There is no point makling a prototype if the end-result is already predetermined as "we don't want it". ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
Charles Wardlaw wrote: > No answer for you. But if people aren't willing to remove that > functionality, or limit it globally in the internal interpreter, then there's > no way to lock things down. > Agreed 100%. The issue, as I keep repeating, is that the ideal solution is that the scripts needing access to file systems, network, etc can get it and those that don't (such as rig constraints and the like) do not. Python, by design, makes this impossible. Other language options do not. > I think there's a difference between users who want inter-program operation > and users who want to do everything inside one software package. Most of the > hobbyist Blender users I know (most, not all) do EVERYTHING inside Blender > and never round-trip to external software. The web-comic artist you spoke of > would not be an entry-level user in my opinion; by the time he's ready to do > stuff like that he's also ready to make the decision to unlock the additional > functionality and drop the security barrier. But until that point, while > he's learning the software and getting to grips with what's possible? No, I > don't think he needs an interchange format. > Actually, I've worked with HER to get her at least familiar with the Blender interface and *trust me* she is an entry-level user. Knowing that she can get a prop out of Poser by following a set of steps (she does not understand) does not mean she knows what a rig script is and/or how it can be abused to compromise her computer. Hell, she would probably think I was being dirty using the term "compromise your computer". We shouldn't confuse being able to import a file (or other simple operations) with understanding how things work. > Agreed, but if the people interested in security aren't interested in writing > C-language "trusted operators" to lock down the system then they must not be > that interested in security, right? > Agreed. But said code needs to be accepted by the core development team. If they hold the view that the operators should stay in Python for "easy modification" (or any other reason really); any effort put into making them C-code is just going to wasted isn't it? > Yes, I did read Campbell's mails. But ANYTHING that's done security-wise can > be cracked! It's not about trying to lock down the system 100% perfectly -- > the only system that's locked down is the one that's unplugged and locked > away from humans. And Blender is worse off from the get-go because all > discussion about security in it is done on an open forum, and the code is > easily perused for holes. > False claim there. A wide variety or studies have shown that opening security code up for public inspection leads to quicker resolution of problems and/or finding out if a solution is going to fail "by design" (as opposed to simply a bug in the implementation). > I was trying to suggest that a compromise might be reached where a bit of > introspection were done. As exploits are discovered you could update the > exploit list in Blender to recognize new code strings. No, it won't catch > everything, but nothing will. Anyway, retracted. > I can see where you are coming from, but it is not a feasible solution. The line quoted by Martin is a basic version of getting around it. I cold base64 encode a string then use eval, I could make a round about function to do it, etc. The issue isn't the WAY it is being done - it is that the functionality is allowed at all in a Python constraint. > I can't speak to the paint programs but I know that buffer exploits have > allowed code to be executed from within MP3 files in the past. No scripting > there, but they were a security risk. And Winamp can play WMA, right? Those > can contain all kinds of crap that gets run through the Windows Media layer > and can install software, pop up IE windows, etc. How many home users who > think in terms of documents, not programs or formats, can differentiate > between WMA and mp3 when the icons are similar? I've known a lot of people > who asked me to help them figure out why WMA files wouldn't play on their MP3 > player. > Buffer overruns are a BUG. The current security issues are a result of mismatched design. Blender developers want to run Python in it's rigs/constraints. Python developers want the namespace browsing features (that are a foundational element of their language) and they want to keep unsecure functions (like the file open() function) as a part of the raw, always available functionality offered by their runtime. If Blender wants to add security, one of these two must give. The issue is a result of "design" not "implementation". Like DRM, the requirement of client-side access to resources post decryption conflicts with the desire for the publisher to stop people from playing the game without their authorisation. One side has to give and, by dint of the fact the client has to be able to play the game, the publisher's desire for
Re: [Bf-committers] "Security" gets in the way
> Raul Fernandez Hernandez wrote: >> Is time to end up this security discussion: paperware is very beautiful >> but never leave the planification phase. >> The pro-security team could work on a prototype that could shut up the >> rest of us that think this discussion is getting in the way, meanwhile, >> the rest of us could continue improving blender. > > Are you speaking for the Blender development team or just yourself? > Serious question as I'd like to know if the opinion that adding security > is not part of "improving Blender" is shared at the top level. After > all, if Ton (for example) doesn't want there to be a security option - > there simply isn't going to be one as it will never get into trunk. > > There is no point makling a prototype if the end-result is already > predetermined as "we don't want it". Don't get me wrong, I have no intention of discrimination , I think the fact that english is not my way of thinking could lead to this. I was speaking for myself , splitting in pro-security and the rest is very natural when a discussion arise, is nothing bad, and when I was referring to "the rest of us could continue improving blender" I didn't mean that working in security was not improving blender, I mean: "the rest of us could continue working in their projects in blender". I think a working patch or prototype is way better than a long discussion that sometimes get out of its path, nothing more. Cheers Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
Hi guys, Is this the list of options? 1. Work with the python team to implement the desired security features into the python trunk. 2. Create a "secure" python fork and implement the desired security features into it. 3. Maintain a trusted/certified/signed repository of scripts and warn users when loading untrusted scripts. 4. Dump python and use something else. 5. Stick with the status quo. (1 or 2) and/or 3 make the most sense to me. 3 by itself seems the least amount of work and seems totally acceptable. Not that I'll be contributing anything other than my opinion. ;) Cheers! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
0. Keep current features, switch from default on to default off. Martin --- On Thu, 4/29/10, Michael Judd wrote: > From: Michael Judd > Subject: Re: [Bf-committers] "Security" gets in the way > To: "bf-blender developers" > Received: Thursday, April 29, 2010, 1:55 PM > Hi guys, > Is this the list of options? > > 1. Work with the python team to implement the desired > security features > into the python trunk. > 2. Create a "secure" python fork and implement the desired > security > features into it. > 3. Maintain a trusted/certified/signed repository of > scripts and warn > users when loading untrusted scripts. > 4. Dump python and use something else. > 5. Stick with the status quo. > > (1 or 2) and/or 3 make the most sense to me. > 3 by itself seems the least amount of work and seems > totally acceptable. > Not that I'll be contributing anything other than my > opinion. ;) > Cheers! > > ___ > 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
Re: [Bf-committers] "Security" gets in the way
6. Create a "secured blender" version of the installer (for platforms that support it) that creates a locked down blender user for executing blender. 7. Provide a downloadable virtual machine (VMWare/Virtual Box/etc.) image. Martin Poirier wrote: > 0. Keep current features, switch from default on to default off. > > Martin > > --- On Thu, 4/29/10, Michael Judd wrote: > > >> From: Michael Judd >> Subject: Re: [Bf-committers] "Security" gets in the way >> To: "bf-blender developers" >> Received: Thursday, April 29, 2010, 1:55 PM >> Hi guys, >> Is this the list of options? >> >> 1. Work with the python team to implement the desired >> security features >> into the python trunk. >> 2. Create a "secure" python fork and implement the desired >> security >> features into it. >> 3. Maintain a trusted/certified/signed repository of >> scripts and warn >> users when loading untrusted scripts. >> 4. Dump python and use something else. >> 5. Stick with the status quo. >> >> (1 or 2) and/or 3 make the most sense to me. >> 3 by itself seems the least amount of work and seems >> totally acceptable. >> Not that I'll be contributing anything other than my >> opinion. ;) >> Cheers! >> >> ___ >> 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 > > -- Michael Judd 853 New Cleveland Rd Gumdale, Qld 4154 Email: m...@juddrobotics.com Phone: +61 (0)7 32452864 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
Ok it seems we are getting nowhere fast on this, so to address the original issue, have it off by default as that is what seems to be causing the most troubles, yet keep it there for those who need it (ie paranoid IT people :) ), as in a studio you will mainly be using internal scripts for like rigs and such not much from the external world also to show the danger to new users put a warning on the download page in nice red letters at the top all of this is done until a suitable option is available, and dropping python all together is certainly not a viable alternative now can this argument please end? -- Michael Fox Developer and user of Blender3d www.blender.org http://mfoxdogg.googlepages.com mfoxd...@gmail.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
Raul Fernandez Hernandez wrote: > Don't get me wrong, I have no intention of discrimination , I think the > fact that english is not my way of thinking could lead to this. I was > speaking for myself , splitting in pro-security and the rest is very > natural when a discussion arise, is nothing bad, and when I was > referring to "the rest of us could continue improving blender" I didn't > mean that working in security was not improving blender, I mean: "the > rest of us could continue working in their projects in blender". > OK, I apologise for misinterpreting you. The lack of clarity as to what will or will not be accepted by core development perhaps makes me read too much into the posts by main developers :) > I think a working patch or prototype is way better than a long > discussion that sometimes get out of its path, nothing more. > The issue I have is that I (or someone else) could put ALOT of work into fixing this without it being accepted into core because they are not interested in what it takes. Security is not like a new operator or constraint. Like the UI refactor - it will affect almost everything in Blender in some way. The amount of work needed even for a basic prototype is substantial. To use a recent example, how do you think a developer would have felt if they put together the Blender 2.5 UI refactor prototype if they knew Ton was against it? I know I wouldn't have bothered. Not because I don't think it is a great feature, but by the very fact it touches almost everything (like security will); it would be impossible to keep up with Blender development through patching a local installation. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
Martin Poirier wrote: > 0. Keep current features, switch from default on to default off. > In which case you may as well not have the feature at all. The people most vulnerable to a malware attack from ANY vector are those that would not know to turn security on. Not to mention the fact that security of an "on/off" variety pretty much hoses any chance of decent rigs whilst having security enabled. As I've mentioned, it's like disabling macros in Office and it not allowing you to use bold fonts and paragraph spacing. Sure you can get around it, but it is not what one would consider a "good solution" ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
There's still very little doubt that this will be the solution that is going to be adopted (in the short to mid term at least). Martin --- On Thu, 4/29/10, Benjamin Tolputt wrote: > From: Benjamin Tolputt > Subject: Re: [Bf-committers] "Security" gets in the way > To: "bf-blender developers" > Received: Thursday, April 29, 2010, 7:46 PM > Martin Poirier wrote: > > 0. Keep current features, switch from default on to > default off. > > > > In which case you may as well not have the feature at all. > The people > most vulnerable to a malware attack from ANY vector are > those that would > not know to turn security on. > > Not to mention the fact that security of an "on/off" > variety pretty much > hoses any chance of decent rigs whilst having security > enabled. As I've > mentioned, it's like disabling macros in Office and it not > allowing you > to use bold fonts and paragraph spacing. Sure you can get > around it, but > it is not what one would consider a "good solution" > ___ > 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
Re: [Bf-committers] "Security" gets in the way
Michael Fox wrote: > Ok it seems we are getting nowhere fast on this, so to address the > original issue, have it off by default as that is what seems to be > causing the most troubles, yet keep it there for those who need it (ie > paranoid IT people :) ), > To be honest, I think the reason it is not getting anywhere is two-fold. Firstly, the "default off" /solution/ that is proposed is *not* a solution. It's like making entering a password optional. Unless it is by default *on*, the people most vulnerable to an attack are going to be those that don't turn it on. > as in a studio you will mainly be using internal scripts for like rigs > and such not much from the external world > OK, and when rigs do come in from the outside world, like in the recent Durian townsfolk sprint, we *know* that those most experienced in Blender will check them for malicious scripts and/or only open them on machines locked out of the network, right? We still haven't got an answer on that. I think that is pretty telling. > also to show the danger to new users put a warning on the download page > in nice red letters at the top > > all of this is done until a suitable option is available, and dropping > python all together is certainly not a viable alternative > Warning, I am happy to have. Without cooperation from the Python development team though, keeping Python is not a viable alternative either. Something might come out of PyPy (currently they still have "all or nothing" security, not context-by-context restriction) which will make this all moot. > now can this argument please end? > I'm simply replying to emails on the subject. It's not like this has been going for a week and debate on controversial subjects like this are not going to be solved by asking people to "just agree". Should one of the core devs ask me to stop mailing on the subject, I will of course do so - it is, after all, their opinion on the matter I am trying to ascertain! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
Martin Poirier wrote: > There's still very little doubt that this will be the solution that is going > to be adopted (in the short to mid term at least). > That doesn't mean I shouldn't disagree with it ;) Apathy results in poor solutions because people give up trying to convince people of the right ones. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
http://www.philhassey.com/blog/tinypy-ideas/ """ Embed tinypy * Objective: sandbox tinypy and then (as in lunatic python) build a python module that uses tinypy for safe execution of “unknown” code """ it's just an idea at the moment and not implemented but this sounds interesting. :) tinypy could be used for drivers in the long term. in the short to mid term there doesn't seem to be an easy and secure solution but in the long term all the "this is impossible with python" seems to be wrong to me. to me it looks like in 2-3 years the whole situation will look different (pypy, tinypy,...) and there will be feasible solutions. On Fri, Apr 30, 2010 at 2:09 AM, Martin Poirier wrote: > There's still very little doubt that this will be the solution that is going > to be adopted (in the short to mid term at least). > > Martin > > --- On Thu, 4/29/10, Benjamin Tolputt wrote: > >> From: Benjamin Tolputt >> Subject: Re: [Bf-committers] "Security" gets in the way >> To: "bf-blender developers" >> Received: Thursday, April 29, 2010, 7:46 PM >> Martin Poirier wrote: >> > 0. Keep current features, switch from default on to >> default off. >> > >> >> In which case you may as well not have the feature at all. >> The people >> most vulnerable to a malware attack from ANY vector are >> those that would >> not know to turn security on. >> >> Not to mention the fact that security of an "on/off" >> variety pretty much >> hoses any chance of decent rigs whilst having security >> enabled. As I've >> mentioned, it's like disabling macros in Office and it not >> allowing you >> to use bold fonts and paragraph spacing. Sure you can get >> around it, but >> it is not what one would consider a "good solution" >> ___ >> 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
Re: [Bf-committers] "Security" gets in the way
Apathy can also result in people giving up trying to convince others of the wrong solutions. It's a double-edge sword. Benjamin Tolputt wrote: > Martin Poirier wrote: > >> There's still very little doubt that this will be the solution that is going >> to be adopted (in the short to mid term at least). >> >> > > That doesn't mean I shouldn't disagree with it ;) Apathy results in poor > solutions because people give up trying to convince people of the right > ones. > ___ > 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
Re: [Bf-committers] "Security" gets in the way
Of course the "this is impossible with python" can be wrong in the long term; who know what direction python will evolve in the next 2-3 years. But trying to find a python solution right now, with what we have, is impossible. I have to agree with what someone posted earlier: if someone is convinced this (a secure solution) can be done with the existing Python 3.1, they need to code up a proof-of-concept to shut up everyone who says it can't be done. Otherwise everyone is just filling up a useful mailing list with spam. horace grant wrote: > http://www.philhassey.com/blog/tinypy-ideas/ > > """ > Embed tinypy > > * Objective: sandbox tinypy and then (as in lunatic python) build > a python module that uses tinypy for safe execution of “unknown” code > """ > > it's just an idea at the moment and not implemented but this sounds > interesting. :) tinypy could be used for drivers in the long term. > > in the short to mid term there doesn't seem to be an easy and secure > solution but in the long term all the "this is impossible with python" > seems to be wrong to me. to me it looks like in 2-3 years the whole > situation will look different (pypy, tinypy,...) and there will be > feasible solutions. > > > > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
I didn't mean that to come across as a personal attack, Benjamin. I'm just pointing out that just because someone has an idea, that doesn't mean it's the right idea. Ken Hughes wrote: > Apathy can also result in people giving up trying to convince others of > the wrong solutions. It's a double-edge sword. > > Benjamin Tolputt wrote: > >> Martin Poirier wrote: >> >> >>> There's still very little doubt that this will be the solution that is >>> going to be adopted (in the short to mid term at least). >>> >>> >>> >> That doesn't mean I shouldn't disagree with it ;) Apathy results in poor >> solutions because people give up trying to convince people of the right >> ones. >> ___ >> 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
Re: [Bf-committers] "Security" gets in the way
Ken Hughes wrote: > I didn't mean that to come across as a personal attack, Benjamin. I'm > just pointing out that just because someone has an idea, that doesn't > mean it's the right idea. > > Ken Hughes wrote: > >> Apathy can also result in people giving up trying to convince others of >> the wrong solutions. It's a double-edge sword. >> Don't worry mate, I got your meaning, even if it didn't quite read that way the first time :) I honestly think the debate is going to fizzle out regardless, because the real decision makers are remaining silent. No solution we come up with, regardless of what we think about, is going to make it into Blender without the core Blender developer's say so. Regardless of the animation/motivation of all sides on this debate, the only concrete thing to have come out of it is Campbell adding a switch to the network render. That's it. It's better than the "default security to off" I am arguing against, but everyone agrees it is not really "a fix". Until there is an official position on the matter, ALL sides of the debate are just shouting into the wind. Sad but true. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
horace grant wrote: > http://www.philhassey.com/blog/tinypy-ideas/ > > """ > Embed tinypy > > * Objective: sandbox tinypy and then (as in lunatic python) build > a python module that uses tinypy for safe execution of “unknown” code > """ > Not a bad idea, though not standard Python. Honestly, if the core Blender developers are willing to relax their "no non-standard Python" stance, it could possibly work. It WOULD require every object in the scene having two "representations", the standard Python object & a TinyPy version. So there will be a hit in memory & code complexity... but it is not "bad by design", which is a step up. My claims about Python being unusable have been based on the fact that Blender devs have stated opposition to using anything but standard Python with standard Python API's. PyPy somewhat fit this bill (for future implementation) as it's stated goal is 1-to-1 compatibility with CPython. Unless this limitation on what Python can be used is removed - my position is still the same. I can actually see their reason behind this too. After all, who is going to fix a bug when a snippet of code syntax/semantics works in an import/export plugin bt fails in the driver due to a TinyPy bug? Whenever Python upgrades, they'd need to wait for TinyPy to catch up on the changes. And heaven forbid the situation where the TinyPy developers throw in the towel and the maintenance (and upgrades) are left to the Blender team. There is a very valid reason for wanting all the scripting to use a standard library supported by a mature, large, and established community. > it's just an idea at the moment and not implemented but this sounds > interesting. :) tinypy could be used for drivers in the long term. > Exactly, the only thing TinyPy would need access to is other elements in the scene. The same could be said of ANY other embedded language solution as well, but there is a large benefit to keeping the same language syntax & semantics throughout. > in the short to mid term there doesn't seem to be an easy and secure > solution but in the long term all the "this is impossible with python" > seems to be wrong to me. to me it looks like in 2-3 years the whole > situation will look different (pypy, tinypy,...) and there will be > feasible solutions. > Mate, the problem is present now. We need to look at solutions *now* not at some years distant time in the future. Can you imagine the lack of advancement in Blender if developers thought "It's too hard now, someone else will have implemented a library we can use in two years time, then we'll look at it"? Advancement comes from those unsatisfied with the status quo and do something about it in the present. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
8. Worry about it when something actually happens and you have a real case to confront, rather than hyperbole. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
Roger Wickes wrote: > 8. Worry about it when something actually happens > and you have a real case to confront, rather than hyperbole This is insulting. The developers have already acknowledged this is an issue. That is why there is the default on security in Blender now. Waiting for someone to be compromised when the problem is *known* is callous and irresponsible. Saying that we delay a solution until we have time to look into it properly is practical. Saying we shouldn't do anything until someone is hurt by it is lazy and unethical. "Yeah, we knew there was a problem with the brakes. But we thought we'd worry about it when something actually happened and had a real case to confront" ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
Ken Hughes wrote: > Of course the "this is impossible with python" can be wrong in the long > term; who know what direction python will evolve in the next 2-3 years. > But trying to find a python solution right now, with what we have, is > impossible. > Bingo. Glad I'm not the only one saying this. We may not agree on the final solution (or that we choose to not have one), but I'm glad that the technical realities are being agreed on. The most frustrating thing in any debate isn't being disagree with on the final answer, it is having to correct people on the facts that make up the debate foundation. Case in point - it is impossible with current versions of Python to secure the loading/rendering of a Blender scene whilst also allowing Python to be embedded in said scene (in constraints, rigs, etc). This is a *fact* given current implementations of Python. > I have to agree with what someone posted earlier: if someone is > convinced this (a secure solution) can be done with the existing Python > 3.1, they need to code up a proof-of-concept to shut up everyone who > says it can't be done. Otherwise everyone is just filling up a useful > mailing list with spam. Another good point. I've been browsing the code whilst the debate has "raged" and the amount of work to move Blender to any other language is phenomenal! If a solution using the standard Python library can be found - I'd be VERY happy to use it. I am not saying Python is bad - it is a very good, mature, and flexible language/platform. It's a little "heavy" for embedding in my projects (and there are thread locking issues); but I use it all the time for data processing tasks. That said, it is *by design* unable to be secured in the way Blender requires if one is going to allow Python expressions in a scene file. I doubt anyone is going to want to look at replacing Python unless there is some nod from the core developers as to it being allowed consideration for trunk. However, a patch to Blender that allows it to be secured whilst still using Python would likely be accepted without much hassle at all. It would be a "bug fix" as compared to an application-wide refactor. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
That was covered by 5. People concerned about malicious scripts already have options to run scripts from the wild in a secure fashion now using a virtual machine or a locked down user on a decent OS. People not concerned about security have probably already been pwned anyway. 5 is a valid choice. Roger Wickes wrote: > 8. Worry about it when something actually happens > and you have a real case to confront, rather than hyperbole. > > > > ___ > 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
Re: [Bf-committers] "Security" gets in the way
Michael Judd wrote: > People concerned about malicious scripts already have options to run > scripts from the wild in a secure fashion now using a virtual machine or > a locked down user on a decent OS. > And as I said before, it is the people that don't know to be concerned that need this the most. Anyone likely to be using your "locked down decent OS" and/or has the skills to setup a virtual machine (ignoring the performance problems that entails) is unlikely to be downloading unsecure scene of the Internet. Remember, even a concientious user who scans the .blend file with an anti-virus is going to still be compromised. > People not concerned about security have probably already been pwned anyway. > People in the graphics industry probably already have Max or Maya, so we shouldn't bother making Blender better. Businesses needing Unix probably already have contracts with IBM, so we shouldn't bother making Linux better People growing up in underprivileged areas are likely to never amount to anything, so we shouldn't bother helping them better themselves. What a wonderful world that would be, eh? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
--- On Thu, 4/29/10, Benjamin Tolputt wrote: > I honestly think the debate is going to fizzle out > regardless, because > the real decision makers are remaining silent. The topic was reopened following a conversation between "decision makers" on IRC. Both of which as well as others have participated in the discussion that followed. To be honest, the decision was pretty much already taken, people just didn't noticed. Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
Martin Poirier wrote: > The topic was reopened following a conversation between "decision makers" on > IRC. Both of which as well as others have participated in the discussion that > followed. > > To be honest, the decision was pretty much already taken, people just didn't > noticed. > Would you be so kind as to let us know what that decision was? After all, not all of us are able to participate in the IRC chats. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
Best bring this up next meeting and come to some consensus. I wasn't in IRC for the decision either :) However I'm going away this weekend, can make it for the next one though (May 9th). Don't thinik this is urgent, can wait a week or two, would rather this be a meeting topic so we can formalize what is done, rather then some devs agreeing on IRC. On Fri, Apr 30, 2010 at 6:25 AM, Benjamin Tolputt wrote: > Martin Poirier wrote: >> The topic was reopened following a conversation between "decision makers" on >> IRC. Both of which as well as others have participated in the discussion >> that followed. >> >> To be honest, the decision was pretty much already taken, people just didn't >> noticed. >> > > Would you be so kind as to let us know what that decision was? After > all, not all of us are able to participate in the IRC chats. > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
Benjamin Tolputt wrote: > People in the graphics industry probably already have Max or Maya, so we > shouldn't bother making Blender better. > Businesses needing Unix probably already have contracts with IBM, so we > shouldn't bother making Linux better > People growing up in underprivileged areas are likely to never amount to > anything, so we shouldn't bother helping them better themselves. > > What a wonderful world that would be, eh? > That's one way of looking at it. I guess some people look at the 1000's of man years of effort that go into creating anti-virus and anti-malware applications for Windows and think of it as a valiant struggle to make the world a better place. Some people no doubt look at it as a total waste of time when there are freely available, virus and malware free options to running Windows in the first place. Obviously someone putting the effort in to increasing security in python and blender would be great. But if no-one is willing to expend the effort, the consequences aren't that dire. There are freely available alternatives. A warning popup at installation time or on the download web page could educate people about the dangers and their options. Though I'm sure all those Windows users that download and run blender with administrator privileges will appreciate your efforts to protect them when they feel compelled to load untrusted blend files (as I no doubt have done myself in the past). ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
Campbell Barton wrote: > Best bring this up next meeting and come to some consensus. I wasn't > in IRC for the decision either :) > Interesting to note :) > However I'm going away this weekend, can make it for the next one > though (May 9th). > Is this a meeting that would be open to other participants? I assume that there are meetings the general public do not attend, but being on IRC - this would be something interested parties can speak at? > Don't think this is urgent, can wait a week or two, would rather this > be a meeting topic so we can formalize what is done, rather then some > devs agreeing on IRC. > This is not that urgent, no. Any immediate changes would still wait for the official Blender 2.5/2.6 release before getting into the hands of the public, and that is some time away. Any non-immediate changes (on the wild, off-chance something drastic is accepted as worth looking into) will need to wait until after said release. In any case, I doubt two weeks are going to matter much either way. Two to three years on the other hand might be asking too much ;) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
I wonder how Sketchup deals with this issue with their embedded ruby... On 4/30/10, Benjamin Tolputt wrote: > Campbell Barton wrote: >> Best bring this up next meeting and come to some consensus. I wasn't >> in IRC for the decision either :) >> > > Interesting to note :) > >> However I'm going away this weekend, can make it for the next one >> though (May 9th). >> > > Is this a meeting that would be open to other participants? I assume > that there are meetings the general public do not attend, but being on > IRC - this would be something interested parties can speak at? > >> Don't think this is urgent, can wait a week or two, would rather this >> be a meeting topic so we can formalize what is done, rather then some >> devs agreeing on IRC. >> > > This is not that urgent, no. Any immediate changes would still wait for > the official Blender 2.5/2.6 release before getting into the hands of > the public, and that is some time away. Any non-immediate changes (on > the wild, off-chance something drastic is accepted as worth looking > into) will need to wait until after said release. In any case, I doubt > two weeks are going to matter much either way. Two to three years on the > other hand might be asking too much ;) > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- Sent from my mobile device >From Luke ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
I'm sorry Ben, I did not mean to offend. "Do Nothing" is always an option, and I was alerted that option 5 already covered it. While I grant you that it is a possibility that something may happen, I was trying to say this thread was like trying to design a building when you don't have a customer, don't know what magnitude earthquakes it has to withstand, what the outside temperature range is, whether it has to be airtight, what gravity is, and all those other unknowns. We could just as easily be sitting here debating the best building solution when one guy is talking about a building in California, another in Finland, and another on the Moon. One guy says we should use Concrete (Lua), another Glass (pypy), and so on. No thread yet that I have seen has identified any specific python call that should be blocked or filtered. The "Do Nothing until it happens" approach is the most efficient way to apply sparse and volunteer labor to "long tails" - events that have not happened but could but have a very low probability of happening. I think we need a real-world case or practical detailed requirements and use cases. --Roger ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
Hi all, As a reminder: IRC meetings are open for everyone. We report on progress, define actions and planning, and make decisions when needed. Meetings are not meant for discussions, for that this list or any time outside meetings is better suited. Decisions are 'in consensis' by default, or at least should be supported by the active maintainers of this part of the code. A solution for this issue would be to appoint a small team to look into this issue, and come with a proposal. This team should consist of active developers/contributors/documentors, and be at least representative for the code or module maintainers. Everyone here has had a chance to reflect opinions and that's loud and clearly heard already. Next step is just accepting a roadmap how to progress, and move on. :) -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 30 Apr, 2010, at 8:29, Benjamin Tolputt wrote: > Campbell Barton wrote: >> Best bring this up next meeting and come to some consensus. I wasn't >> in IRC for the decision either :) >> > > Interesting to note :) > >> However I'm going away this weekend, can make it for the next one >> though (May 9th). >> > > Is this a meeting that would be open to other participants? I assume > that there are meetings the general public do not attend, but being on > IRC - this would be something interested parties can speak at? > >> Don't think this is urgent, can wait a week or two, would rather this >> be a meeting topic so we can formalize what is done, rather then some >> devs agreeing on IRC. >> > > This is not that urgent, no. Any immediate changes would still wait > for > the official Blender 2.5/2.6 release before getting into the hands of > the public, and that is some time away. Any non-immediate changes (on > the wild, off-chance something drastic is accepted as worth looking > into) will need to wait until after said release. In any case, I doubt > two weeks are going to matter much either way. Two to three years on > the > other hand might be asking too much ;) > ___ > 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
Re: [Bf-committers] "Security" gets in the way
Sorry if this discussion is considered closed, but I wanted to read everything before chiming in. On Wed, Apr 28, 2010 at 9:06 AM, Benjamin Tolputt wrote: > However, the "sand-boxing" as presented in PyPy is very crude and will > do nothing to fix the issues with Python in Blender. I think this is incorrect. The way PyPy is implemented presents a possible solution. Depending on the maturity of PyPy this may be ways off, so I'm just throwing this out to be considered. PyPy is a meta-circular interpreter, what that boils down to is the fact that you can implement a python interpreter in the language with a small amount of python code. But, you don't have to implement a perfect python interpreter, you can change it a little, for example, you could inspect every function before it is dispatched and make sure it is on a white list. It seems to me a possible solution is to implement a python interpreter (in PyPy) that has a white list of functions that are allowable in certain contexts within Blender. The whole idea behind a meta-circular interpreter is that you can implement the language easily in itself, and then hack your implementation to change the language itself to your needs. Also, maybe this doesn't depend on PyPy, but maybe it is possible to write a meta-circular interpreter in the standard python distribution (I'm not a python programmer, but I know how I'd do this in Scheme :). ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
hi. All: I have commented extensively about the present Blender Security Model. See: http://lists.blender.org/pipermail/bf-committers/2010-March/026604.html http://lists.blender.org/pipermail/bf-committers/2010-March/026615.html I helped Leif to write up his GSOC proposal for a Security model that is abstracted away from interpreter/ API implementation constraints, which the current discussion seems mired in. PyPy, Lua, et al are not the root of the problem, and any such implementation would be necessarily constrained. The root of the problem is well articulated in the idea of Trust. Happily there are well proven ways to represent trust algorithmically. These ways are well established and adopted by the Free Software community at large. I plead with you all to learn about GnuPG, and the Web Of Trust (see above messages, including extensive citations to which you are invited to read). Ton, and Tom, please include me in the list of contributors for the Blender Security working group. Thanks. have a day.yad jdpf On Apr 30, 2010, at 8:06 AM, Ton Roosendaal wrote: > Hi all, > > As a reminder: IRC meetings are open for everyone. We report on > progress, define actions and planning, and make decisions when needed. > Meetings are not meant for discussions, for that this list or any time > outside meetings is better suited. > > Decisions are 'in consensis' by default, or at least should be > supported by the active maintainers of this part of the code. > > A solution for this issue would be to appoint a small team to look > into this issue, and come with a proposal. This team should consist of > active developers/contributors/documentors, and be at least > representative for the code or module maintainers. Everyone here has > had a chance to reflect opinions and that's loud and clearly heard > already. Next step is just accepting a roadmap how to progress, and > move on. :) > > -Ton- > > > Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org > Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands > > On 30 Apr, 2010, at 8:29, Benjamin Tolputt wrote: > >> Campbell Barton wrote: >>> Best bring this up next meeting and come to some consensus. I wasn't >>> in IRC for the decision either :) >>> >> >> Interesting to note :) >> >>> However I'm going away this weekend, can make it for the next one >>> though (May 9th). >>> >> >> Is this a meeting that would be open to other participants? I assume >> that there are meetings the general public do not attend, but being on >> IRC - this would be something interested parties can speak at? >> >>> Don't think this is urgent, can wait a week or two, would rather this >>> be a meeting topic so we can formalize what is done, rather then some >>> devs agreeing on IRC. >>> >> >> This is not that urgent, no. Any immediate changes would still wait >> for >> the official Blender 2.5/2.6 release before getting into the hands of >> the public, and that is some time away. Any non-immediate changes (on >> the wild, off-chance something drastic is accepted as worth looking >> into) will need to wait until after said release. In any case, I doubt >> two weeks are going to matter much either way. Two to three years on >> the >> other hand might be asking too much ;) >> ___ >> 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
Re: [Bf-committers] "Security" gets in the way
Jason Wilkins wrote: > I think this is incorrect. The way PyPy is implemented presents a possible > solution. Depending on the maturity of PyPy this may be ways off, so I'm > just throwing this out to be considered. > > PyPy is a meta-circular interpreter, what that boils down to is the fact > that you can implement a python interpreter in the language with a small > amount of python code. > I am not against an embedded Python interpreter at all. In fact, if you look at my recent comments I'm kind of leaning that way. It is not the "concept" I think will not work, but the "current PyPy implementation" which is unworkable. The current sandbox implementation of PyPy is a crude "all or nothing" mechanism. Which works well for running Python where you want the same permissions throughout the application. This is not the case in Blender where plugins need access to the network & file system but the scene itself does not. On the other hand, extracting a Python interpreter that only allows the calling of white-listed functions and limits the namespace to the data within the scene only (i.e. I cannot find restricted modules/data by browsing the namespace) from PyPy or another program is not a terrible idea. I believe that resistance to this idea is based around the very valid question of "Who is going to maintain this subset interpreter?". What happens when PyPy makes an incompatible change or the standard Python distro moves ahead of PyPy and there is a mismatch between the syntax semantic used in scripts & scene drivers? These are all valid concerns for a "graphics application project" without a huge pool of "Python engine coders" available. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
I believe that security is 10% technical and 90% social problem, so "web of trust" + educating users on security issues seems to be most logical solution and requires the least amount of changes in Blender's and third party plugins' code. It seems to work for Mozilla Firefox, for example, which is another OSS project that has a rich plugin infrastructure. And it's killing two birds with one stone: both security and usability. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
On Fri, Apr 30, 2010 at 7:39 PM, Benjamin Tolputt wrote: > I believe that resistance to this idea is based around the very valid > question of "Who is going to maintain this subset interpreter?". I understand this and is why I need to look and see just how simple it is to write a python interpreter in pypy. If pypy really is a "meta-circular interpreter" it should be a small amount of code to maintain. For example, a Scheme interpreter, written in Scheme is tiny. Most people probably think of how difficult it is to write a python interpreter in C and think it would be a ton of code but it could actually be very simple if written in PyPy. I won't say much more until I actually find the time to look at it though. On Fri, Apr 30, 2010 at 9:05 PM, Ruslan Merkulov wrote: > I believe that security is 10% technical and 90% social problem, so > "web of trust" + educating users on security issues seems to be most > logical solution I totally agree with this. However, the 10% still needs to be done and I think that part of that 10% is at least declaring that rigs should not be able read files and connect to the internet unless the user really wants them to. That's my 2 cents :) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
Jason, there is already a sandbox version of pypy. http://codespeak.net/pypy/dist/pypy/doc/sandbox.html As regards web of trust and GPG, there is python GnuPG http://code.google.com/p/python-gnupg/ LetterRip ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
Ruslan Merkulov wrote: > I believe that security is 10% technical and 90% social problem, so > "web of trust" + educating users on security issues seems to be most > logical solution and requires the least amount of changes in Blender's > and third party plugins' code. It seems to work for Mozilla Firefox, > for example, which is another OSS project that has a rich plugin > infrastructure. And it's killing two birds with one stone: both > security and usability. You are ignoring the difference between DOCUMENT and PLUGIN. Yes, Mozilla relies on the user to trust the owner of the plugins they install. But any documents opened in the browser are secured from wiping your hard-drive. This is the concept alot of people get confused about. No-one I know is saying that the plugins & external scripts need to be secure. They NEED access to sensitive resources (network, file system, etc) to do their job. It is the fact that scripts within the blend file for the scene, or "document", have access to the same level of functionality. Any document that can be opened in FireFox and read/write files on your hard-drive is rightly classified as exposing a bug in the software. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
Tom M wrote: > there is already a sandbox version of pypy. > > http://codespeak.net/pypy/dist/pypy/doc/sandbox.html > The sandbox described in that page is not exactly what he is talking about. That is a Python-wide sandbox that shunts all sensitive functionality (file access, sockets, OS operations, etc) to an external EXE file that then handles them. What I think Jason is talking about is building a subset of Python using PyPy that simply does not provide access to these modules AT ALL. This would be an ideal solution if it can be implemented in a reasonably maintainable manner. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
I think the complaint was that as is pypy was all or nothing sandboxing. I was proposing writing a pypy hosted interpreter that had the specific features required. Too bad I have other fish to fry or I'd build a prototype On Apr 30, 2010, at 10:07 PM, Tom M wrote: > Jason, > > there is already a sandbox version of pypy. > > http://codespeak.net/pypy/dist/pypy/doc/sandbox.html > > > As regards web of trust and GPG, there is python GnuPG > > http://code.google.com/p/python-gnupg/ > > LetterRip > ___ > 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
Re: [Bf-committers] "Security" gets in the way
As a subscriber to this list and long time blender user I thought I would add my opinion. I for one welcome the check box to dissable running python scripts on open and the trusted source override in the open blend file dialog box. With my setting set to OFF, not to run python scripts on launch, I simply remember to override when loading certain files. Simple and Safe I do use blender in a production environment. I do help many blender users through out the day often times download blend files from stangers. So again, I really like current implementation and had NO PROBLEM adapting to new workflow. jsplifer ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
something else came to my mind. the problem of the OP was that rigs didn't work anymore and he at first had no idea why, which did cost him a lot of time... what about keeping the global security setting just like it is at the moment but instead of simply ignoring drivers when the setting is OFF, displaying some warning popup "warning: drivers not evaluated due to security settings!" if drivers get found in the blend file. wouldn't this clear everything up and be an ok solution in the meantime until there is a useable python sandbox project? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
