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

amrphoto1 at gmail.com amrphoto1 at gmail.com
Thu Apr 29 05:27:31 CEST 2010


Hey Guys,

Thoughts on security issues.

Why can't the devs with the know how, or the ones that desire the challenge and the kudos, take some time and hard code the "most worthy" script functionality into Blender?  

Many of the scripts seem to fill in the gaping holes in Blender's functionality as compared  to the paid programs, anyhow. Python is the common language, that many humans can dabble in and provide prototypical solutions to new functions, but can't the devs who are competent in C take this functionality and incorporate it directly into Blender?

Best,
AMR
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Benjamin Tolputt <btolputt at internode.on.net>
Date: Thu, 29 Apr 2010 11:45:20 
To: Benjamin Tolputt<btolputt at internode.on.net>; bf-blender developers<bf-committers at blender.org>
Subject: Re: [Bf-committers] "Security" gets in the way

Sorry if this is a repost - I sent this hours ago and it never turned up
in my inbox (unlike others I sent more recently). Ignore this if the
mailing list already has a copy.

Note that I am replying to all of last night's posts - Matt's is just
the last in the list & he hits most bases I want to cover.

Matt Ebb wrote:
>> What ?! how come the discussion started with "current blender defaults are
>> getting in the way with production" which I totally agree and switched to
>> "Let's replace Python with something else" ???    
>
> Yes, this is getting silly, and I think is representative of the problem.
>   

To answer the first question, the reason "replacing Python" comes up in
the security context is because the source of the security problem is
Python's inability to restrict access to built-in functionality
depending on context. To fix this security hole (and there is no debate
now it IS a security hole) the effort can be spent on one of two things:

    * Fixing Python so it can have it's functionality limited as & when
      required
    * Remove Python from Blender & replacing it with an alternate
      scripting solution.

Regardless of whether people like the choices or not - that is the
reality of the situation. Either Python changes or Blender does, but for
security to be obtained you cannot have both. The only way out of making
this problematic choice (in the end) is to ignore security completely.

The concept that debate is silly because some people don't like the fact
the choices have been limited by prior decisions in Blender's history
is, quite frankly, *insulting*. Security is ALWAYS a trade-off,
especially when it comes to being able to run arbitrary script embedded
in a "document" or scene file.

Look at Word macros and the worms that resulted from that. No-one argues
that the macros were useful, anymore than people argued the usefulness
of ActiveX web add-ons or the fact that not having a password is easier
than having to enter one all the time. Regardless of how skilled &
intelligent people are in their area of expertise, a good majority of
them are unaware and simply don't care about security implications until
such time as it wipes their hard-drive or kills their Internet
connection due to spam activity overload. This does not make it any less
important a subject for consideration. Seat belts too are a pain until
the one time they save your life.

> I can see two major perspectives here: a) those from an IT background,
> where security is very important and security is often a number one
> priority and b) those who use blender in production, where having a
> functional 3d application is a number one priority.
>   

This is a false choice that unfairly maligns those on the side of
security as "theoretical IT types" as opposed to the "practical Blender
users". A more accurate description, without generalising the reasons
WHY people are for/against security is simply that there are those that
desire security in Blender and those that don't particularly care. Those
that want security consider the trade-offs involved (some more drastic
than others) whereas those that don't particularly care see ANY
trade-off as a negative.

That said, a trade-off that results in unworkable files ALL THE TIME as
is being suggested by Matt is not a viable one. Especially given the
fact that the security issue is not resolved because to make use of any
reasonably complex rig nowadays, you need to enable Blender. Meaning
that to even try out that cool rig from Artist X's website, you need to
disable security... which defeats the purpose of having it in the first
place. I cannot think of ANY rig that needs access to my hard-drive to
work yet almost EVERY rig worth downloading and looking at requires
scripted expressions which, in turn, gives it access to my hard drive.
The all or nothing approach is not a reasonable trade-off, even for this
"IT background" end-user who wants security.

> The fact that people are even suggesting to drop Python is an example
> of this - placing security in the sense of protecting some contingent
> of users from themselves, as having higher importance than the pain of
> completely re-doing Blender's main scripting language which is working
> very well, that hundreds if not thousands of users depend on, have
> spent years learning, and which is the standard language of the 3D
> industry. It just shows how wide the disconnect is. Clearly I don't
> think this mindset should be driving a discussion that has clear,
> practical and costly implications for the people that are actually
> using Blender.
>   

Quite frankly, being the best open-source / free 3D modelling, rigging,
animation, etc program available (and yes, I really do think that - the
other open-source/free apps don't come near EVERYTHING Blender can do...
even if Wings is much nicer to model in *grin*) means that the
"contingent of users" needing protection not from themselves but from
malicious developers who count on their lack of security awareness far
outnumbers those using Blender in a production environment. They might
not use it for long, to make money, or for much more than rendering
naked models from MakeHuman; but they likely outnumber the "production
users" ten-to-one. Security holes don't particularly care what you use
the application for (which is why bot-nets have been detected inside
national defence networks) or how long you use it, only that you somehow
make them available to an exploit.

That said, the only reason there is the suggestion that Python be
removed is because Python is the problem. Or more accurately, the
inability to limit Python functionality to a subset of it's loaded
libraries & modules is the problem. Were there some way in which
security could be achieved with security, I for one would be very
strident in my opposition to those wanting to remove it.

To use an analogy, think of the arguments that were used against tobacco
taxes & health warnings. Yes, the tobacco industry employed alot of
people and changes to the laws around it will affect the economy. Yes,
many people liked to smoke and your grandmother smoked like a chimney
and lived to ninety. But there is no denying the fact smoking causes
cancer. Same situation here.  Yes, people have gotten used to Python and
it is strongly enmeshed in the Blender code. Yes, Python is a great
language with an extensive set of libraries. And no-one (yet) has had
their hard-drive wiped from a malicious Python rig. But there is no
denying the fact that Python's very design opens q security hole that
can be used for this.

> The very big problem now is that Blender is not functional by default
> - very important parts of it do not work after you install it. Your
> own files *don't work*. This is a very stupid situation to be in, and
> needs to be changed.
>   

As I mention above - this is something I agree with. My contention is
the fact that the argument is framed as those with "security" as their
priority against those with "Blender" as their priority. One is not
mutually exclusive of the other and suggesting otherwise is a dishonest,
nay, a *manipulative* method to shut down debate. I'm not stating that
those interested in having Blender usable are ok with your machine being
made a minion in some malware author's bot-net army. A bit of respect
for other people's perspective might be nice.

Simply put, the current situation is not an acceptable trade-off and I
fully accept that. Given how essential Python is to a decent rig
nowadays, having an all or nothing switch for it is like saying you can
disable Word macros but that also means you'll have to do without bold &
italic formatting options. I support your desire to see this change - I
simply don't support your characterisation of those wanting to see
Blender secured.

Some related asides follow:

*Mono*:
On the suggestion of Mono, this is a no-go before it even get's to the
starting block. The components needed to make Mono run are quite large
in size and not guaranteed to be on every machine. Currently Blender
runs just fine by distributing the required Python dependencies along
with it (though it locates existing installations just fine as well).
Doing the same for Mono would blow out the download size of the default
Python by a large factor.

*Python is the standard 3D application language:*
Actually it isn't, though it might be one used most often. Maya & XSI
include it embedded "as is" with the capability on every load of turning
off script execution on load. Part of the reason for this not being a
hindrance is that Maya/XSI allow for expressions to be used in rigs that
are not in Python and unable to access resources they should not. In
other words, one can make a rig in these applications with complex logic
tying it together without exposing it to the security hole in Python.
Note that, unlike Maya, XSI uses Python only for "plugins" not for
expressions built into a scene.

Lightwave actually exposes a SWIG interface to scripting languages.
Python can access this and so can be used, but they make explicit
mention of other languages that can use this interface, funnily enough
naming Lua as the example of an alternative. That is, they relegate the
security issue to the language people develop their PLUGINS for (as this
is an SDK extension, not used for the expressions used in rigs) and it
is not a necessary component of a scene. Again, an application where
Python is external to the scene and simply a method of extending the
application through a script rather than a compiled extension.

I cannot find any reference for 3D Studio Max using Python internally,
but am willing to concede it probably does. That said, given the lack of
reference material
about it in Google, I am going to assume that like XSI & Lightwave that
(if it is integrated) Python is a method for extending the APPLICATION,
not the SCENE.

*PyPy as a solution:*
The problem with PyPy is that, like the current situation, it is an all
or nothing approach. PyPy will give you the choice of allowing Blender
to access your file system (a requirement for import/export scripts) or
will lock it down. Recall that the problem with Python isn't that it can
allow access to the hard-drive, but that either EVERY Python script &
expression can do it or none of them can. Rigs don't need access to the
network, file systems, operating system features etc; but if we give it
to the import/export scripts - we give it to the rigs. Python's all or
nothing problem is based on the language design & modules developed
around it, not the virtual machine used to execute the code (which is
all PyPy is attempting to change).
_______________________________________________
Bf-committers mailing list
Bf-committers at blender.org
http://lists.blender.org/mailman/listinfo/bf-committers


More information about the Bf-committers mailing list