[Bf-committers] "Security" gets in the way

[Charles Wardlaw]

> 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