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

Benjamin Tolputt btolputt at internode.on.net
Thu Apr 29 16:11:49 CEST 2010


Charles Wardlaw wrote:
> 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.
>   

Agreed 100%. The issue, as I keep repeating, is that the ideal solution
is that the scripts needing access to file systems, network, etc can get
it and those that don't (such as rig constraints and the like) do not.
Python, by design, makes this impossible. Other language options do not.

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

Actually, I've worked with HER to get her at least familiar with the
Blender interface and *trust me* she is an entry-level user. Knowing
that she can get a prop out of Poser by following a set of steps (she
does not understand) does not mean she knows what a rig script is and/or
how it can be abused to compromise her computer. Hell, she would
probably think I was being dirty using the term "compromise your
computer". We shouldn't confuse being able to import a file (or other
simple operations) with understanding how things work.

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

Agreed. But said code needs to be accepted by the core development team.
If they hold the view that the operators should stay in Python for "easy
modification" (or any other reason really); any effort put into making
them C-code is just going to wasted isn't it?

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

False claim there. A wide variety or studies have shown that opening
security code up for public inspection leads to quicker resolution of
problems and/or finding out if a solution is going to fail "by design"
(as opposed to simply a bug in the implementation).

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

I can see where you are coming from, but it is not a feasible solution.
The line quoted by Martin is a basic version of getting around it. I
cold base64 encode a string then use eval, I could make a round about
function to do it, etc. The issue isn't the WAY it is being done - it is
that the functionality is allowed at all in a Python constraint.

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

Buffer overruns are a BUG. The current security issues are a result of
mismatched design. Blender developers want to run Python in it's
rigs/constraints. Python developers want the namespace browsing features
(that are a foundational element of their language) and they want to
keep unsecure functions (like the file open() function) as a part of the
raw, always available functionality offered by their runtime. If Blender
wants to add security, one of these two must give.

The issue is a result of "design" not "implementation". Like DRM, the
requirement of client-side access to resources post decryption conflicts
with the desire for the publisher to stop people from playing the game
without their authorisation. One side has to give and, by dint of the
fact the client has to be able to play the game, the publisher's desire
for a lock-down on content is usually the one that fails.

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

I don't see much difference in concept, only in output; but I will
concede this is a "personal perspective" thing. Of the three entry level
users I know (i.e. without background in computers &/or 3D graphics
applications), all of them talk about Blender in the same terms as they
would desktop publishing. They "open" a scene/spreadsheet, the "edit"
the contents to look right, they render/print the "final result".

> Anyway, I'm tapping out of this thread.
>   

I can understand that too :) Thanks for thrashing things out with us.
Whilst a solution was not forthcoming, it was bound to be informative
for someone reading in.


More information about the Bf-committers mailing list