> 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?
No answer for you. But if people aren't willing to remove that functionality, or limit it globally in the internal interpreter, then there's no way to lock things down. > I think the biggest problem is that everyone is looking for an "easy > answer" and there simply isn't one. Agreed. > ...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. I think there's a difference between users who want inter-program operation and users who want to do everything inside one software package. Most of the hobbyist Blender users I know (most, not all) do EVERYTHING inside Blender and never round-trip to external software. The web-comic artist you spoke of would not be an entry-level user in my opinion; by the time he's ready to do stuff like that he's also ready to make the decision to unlock the additional functionality and drop the security barrier. But until that point, while he's learning the software and getting to grips with what's possible? No, I don't think he needs an interchange format. > 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. Agreed, but if the people interested in security aren't interested in writing C-language "trusted operators" to lock down the system then they must not be that interested in security, right? > 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. Yes, I did read Campbell's mails. But ANYTHING that's done security-wise can be cracked! It's not about trying to lock down the system 100% perfectly -- the only system that's locked down is the one that's unplugged and locked away from humans. And Blender is worse off from the get-go because all discussion about security in it is done on an open forum, and the code is easily perused for holes. I was trying to suggest that a compromise might be reached where a bit of introspection were done. As exploits are discovered you could update the exploit list in Blender to recognize new code strings. No, it won't catch everything, but nothing will. Anyway, retracted. > 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'm doing nothing of the sort. I myself have been tired and downloaded the wrong thing from the wrong site and ended up with a bricked XP machine more than once. I also once ended up with a virus just for having MSN messenger installed, even though I wasn't logged in, because someone else on my network had some crafty virus that jumped between machines through Messenger's port. In other words, I've been an "idiot" on a number of occasions, as have we all at some point or another. One of the main reasons I use a Mac for my main machine is because I don't want to have to constantly be proactive about those kinds of issues. What I am saying is that providing messages in prominent places, educating users instead of being their parents, would likely go further than blanket security solutions. I can't speak to the paint programs but I know that buffer exploits have allowed code to be executed from within MP3 files in the past. No scripting there, but they were a security risk. And Winamp can play WMA, right? Those can contain all kinds of crap that gets run through the Windows Media layer and can install software, pop up IE windows, etc. How many home users who think in terms of documents, not programs or formats, can differentiate between WMA and mp3 when the icons are similar? I've known a lot of people who asked me to help them figure out why WMA files wouldn't play on their MP3 player. Open Office can pop open a window, sure, but Open Office and Blender are completely different kinds of content creation platforms. (God, did I just say that?) You're not going to be rendering Excel files in a process all weekend. However, maybe the solution is the same -- pop up a window when untrusted .blends are loaded in windowed mode. Campbell already added the new flag for render farms, so that solves that side of it. And the rest of us can modify the source to build with security off by default, right? Anyway, I'm tapping out of this thread. ~ C _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
