hi. First off, Leif, thanks for volunteering to study this set of ideas! And thanks to all for the excellent comments and opinions expressed so far!
I would like to forward what I've been calling my axiom of usability in computer security for the last 10 years or so: "Computer security is inversely related to the usability of a system. The more secure, the less usable. The less secure, the more likely it is to be usable." Good computer security, these days, has become a usability problem, because computer security is *complicated* and users don't like *complicated.* Yet as the malware industry (estimated at $1+ billion and growing) continues to grow, the exploits will only become more and more sophisticated. End users must be educated, and that's a big reason why I'm suggesting a Web of Trust model. That model can be limited to any population we wish. I agree that it should Just Work. Seeing the success of the Web of Trust in the Debian and Ubuntu operating systems, it is quite evident to me that asking for a clear chain of cryptographically verifiable identity through a Web of Trust model, is not only doable, but when carefully implemented, will protect end users from malicious code, in any language, leaving the blender coders free to make system changes as they see fit. Blender is becoming a *distribution.* It is likely to rapidly be exiting the realm of an "application" in short order, as Leif points out. Blender is GPL, and that is a very good thing for security, as it allows for peer review. AFAIK, Python scripts written to run in blender will also be required to be GPL. Concerned users can read over the code prior to execution. The injection of a "do you trust X?" dialog only solves half of the problem, however. The other half is that of verifying the identity of X. Creating a central distribution system is also a fine thing--- but it does not address the problem of trust fully--- and requires time on the behalf of those who are charged with the task of vetting what is allowed in that "plugin repository." I am fully in support of a centralized, or decentralized web of plugin repositories. It follows, to me, that each extension or plugin or file should be independently verifiable, however. That verification should *become* automatic for 99% of the cases in the Web of Trust model, reducing the requirement of intervention on the behalf of the user. Firefox doesn't actually offer any trust metric at all. End users just "use the plugins." Further, Firefox is *fundamentally* different in form, and function from blender--- it is not a content creation tool--- it is a content browser. While one *can* get a plugin to create content, that is not, and was not, the primary purpose. That's an important distinction. Blender does not have the same luxury of limiting script capability. The goal is to prevent someone from executing a malicious bit of software. This is a very very challenging problem. Computer security experts have spent decades and billions of (government) dollars trying to arrive at perfect solutions to this problem. As far as I know, no such *perfect* solutions exist--- but many solutions do exist, and the appropriateness of the solution depends on the use case. Sandboxing (a form of mandatory access control) and a GnuPG Web of Trust (whether centralized or decentralized), are potentially good solutions--- but we need to evaluate the merits of each for the blender community. I've "been there, done that" with the sandbox in currently shipping commercial software, and don't actually believe that it is the best solution for the blender community, especially given how we in that community work, and share files. I believe that blender's community is growing, and that it is a cutting-edge community. Many members of the blender community already know and trust each other, so making a Web of Trust will only serve to strengthen the blender community. Finally, I point out that a Web of Trust is not inherently restricted to closed communities at all. Most individuals will only need to trust a few sources, the most trusted being the centralized source. Blender, is itself, a very cutting-edge system, and the tight integration of python in blender is part of what makes it so cutting edge. Bringing blender towards a socially verifiable web of trust, will go farther than any other "application" that I know of, to validate "plugins" or "extensions" or .blend files. On Mar 17, 2010, at 9:45 PM, Brecht Van Lommel wrote: > Hi, > > On Thu, Mar 18, 2010 at 1:51 AM, Benjamin Tolputt > <btolp...@internode.on.net> wrote: >>> To sum up my opinion, sandboxing is very hard and not something we >>> can >>> solve once, it requires continuous attention, so let's not even try >>> it. Instead, the install addon operator should warn about security >>> problems, and loading a .blend file with scripts should become >>> easier >>> for users. >>> I fully agree. Avoiding an arms race is wise in any case. While the principle of sandboxing is easy doing it *well* can be very hard--- regardless of the language used due to the depth of integration needed for blender. I continue to be very excited about blender's generated python API. It will enable many rapid improvements in usability for end users. The blender developers have worked hard to create a graduated use-curve for making mere users into python script writers. This is a wonderful effort, and I applaud the blender project for doing so. I argue that the more sophisticated the system, the harder it is to create some kind of Mandatory Access Control layer, of which a sandbox is only the beginning. Jails, chroots, application firewalls, trusted operating systems, (of which TrustedBSD and SELinux are the only remaining examples still under active development) all of these solutions lead rapidly down a path of security policy making. In my experience, such solutions end up shifting the problem to a "security expert" who then spends time making sophisticated policies to protect a sophisticated API. I remind you that blender developers *deliberately* fully exposed the API for a wide variety of very good reasons, and a language shift will not, in my opinion, really solve much of anything, as the need for the API will continue to exist. >> Actually, sand-boxing scripts is quite easy provided you use a >> platform >> that supports it. I agree with Brecht. It might be easy for the first few API calls, but as those calls (instructions) become more sophisticated, the level of attention, detail, and work required to support that "sandbox" becomes ever larger. At the risk of sounding hyperbolic, I do not wish blender to enter the malware arms race. Blender will lose. Limiting functionality of such an amazing tool is also quite unacceptable to me. >> Python currently does not support this so the task >> seems insurmountable; but only so long as you look through the Python >> lens. It is quite simple to sandbox applications using Lua - simply >> don't give them access to the unsecure functionality. If you don't >> want >> the user reading/writing files not explicitly handed to them? Then >> don't >> give them access to the "io" library (by excluding it from the VM's >> initialisation). Don't want to give the person access to the >> operating >> system, don't add the "os" module to those accessible by the VM. >> And so on. > I don't think making the Blender API safe is easy. Some examples of > things that could be exploited: > * .blend/image/sound save operators > * render animation operator > * physics systems point caches writing to disk > * open file browser + run file delete operator > * binding keymap or buttons to an operator > * compositing file output node > * register operator to override .obj exporter > > And then there are of course the more complicated ones, memory > corruption, buffer overruns, etc now become security issues. I bet you > can find dozens of indirect an non-obvious ways to do damage. Now, you > can try to figure out all those cases and add checks for them, but > doing this well is really hard. Security issues in web browsers don't > happen because they forgot to disable access to the IO module. And as > new features are added to Blender this does require continuous > attention. Again, I fully agree with Brecht. Let's please avoid an arms race here. I believe that it will ultimately stall blender development. It may not for many years to come, but I have no idea when it will become an unmanageably difficult issue. Finally, I don't hear about malware targeting Maya much. As far as I know, Autodesk does nothing to protect a user from malware with python. Blender's current default of disabling a script in a .blend file goes a good distance towards protecting end users from malicious scripts. But it too, is only part of the larger solution. Thanks for the lively conversation! have a day.yad jdpf _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers