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. _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
