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

[Benjamin Tolputt]

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 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.
>   

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 repeat my question from last email - did anyone on the Durian team
"scan" the results of the town-folk modelling/animation sprint for
malicious scripts or did they just open them up to take a look? I've got
a pretty good idea which it is because, as their blog has indicated,
they are running behind their expected timetable and are rushing to
catch up. These are the "professionals" you talk about who know the
potential problems with doing this.