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 <btolp...@internode.on.net> Date: Thu, 29 Apr 2010 11:45:20 To: Benjamin Tolputt<btolp...@internode.on.net>; bf-blender developers<bf-committers@blender.org> 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 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 their lack of security awareness far outnumbers those using Blender in a production environment. They might not use it for long, to make money, or for much more than rendering naked models from MakeHuman; but they likely outnumber the "production users" ten-to-one. Security holes don't particularly care what you use the application for (which is why bot-nets have been detected inside national defence networks) or how long you use it, only that you somehow make them available to an exploit. That said, the only reason there is the suggestion that Python be removed is because Python is the problem. Or more accurately, the inability to limit Python functionality to a subset of it's loaded libraries & modules is the problem. Were there some way in which security could be achieved with security, I for one would be very strident in my opposition to those wanting to remove it. To use an analogy, think of the arguments that were used against tobacco taxes & health warnings. Yes, the tobacco industry employed alot of people and changes to the laws around it will affect the economy. Yes, many people liked to smoke and your grandmother smoked like a chimney and lived to ninety. But there is no denying the fact smoking causes cancer. Same situation here. Yes, people have gotten used to Python and it is strongly enmeshed in the Blender code. Yes, Python is a great language with an extensive set of libraries. And no-one (yet) has had their hard-drive wiped from a malicious Python rig. But there is no denying the fact that Python's very design opens q security hole that can be used for this. > 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. > As I mention above - this is something I agree with. My contention is the fact that the argument is framed as those with "security" as their priority against those with "Blender" as their priority. One is not mutually exclusive of the other and suggesting otherwise is a dishonest, nay, a *manipulative* method to shut down debate. I'm not stating that those interested in having Blender usable are ok with your machine being made a minion in some malware author's bot-net army. A bit of respect for other people's perspective might be nice. Simply put, the current situation is not an acceptable trade-off and I fully accept that. Given how essential Python is to a decent rig nowadays, having an all or nothing switch for it is like saying you can disable Word macros but that also means you'll have to do without bold & italic formatting options. I support your desire to see this change - I simply don't support your characterisation of those wanting to see Blender secured. Some related asides follow: *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. *Python is the standard 3D application language:* Actually it isn't, though it might be one used most often. Maya & XSI include it embedded "as is" with the capability on every load of turning off script execution on load. Part of the reason for this not being a hindrance is that Maya/XSI allow for expressions to be used in rigs that are not in Python and unable to access resources they should not. In other words, one can make a rig in these applications with complex logic tying it together without exposing it to the security hole in Python. Note that, unlike Maya, XSI uses Python only for "plugins" not for expressions built into a scene. Lightwave actually exposes a SWIG interface to scripting languages. Python can access this and so can be used, but they make explicit mention of other languages that can use this interface, funnily enough naming Lua as the example of an alternative. That is, they relegate the security issue to the language people develop their PLUGINS for (as this is an SDK extension, not used for the expressions used in rigs) and it is not a necessary component of a scene. Again, an application where Python is external to the scene and simply a method of extending the application through a script rather than a compiled extension. I cannot find any reference for 3D Studio Max using Python internally, but am willing to concede it probably does. That said, given the lack of reference material about it in Google, I am going to assume that like XSI & Lightwave that (if it is integrated) Python is a method for extending the APPLICATION, not the SCENE. *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). _______________________________________________ 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