[Bf-committers] Blender 2.5 malicious scripting

[Benjamin Tolputt]

Rick Yorgason wrote:
> It would be a bit of extra maintenance, and I'm sure it's out of the
> question to even consider this for 2.6, but you could possibly maintain
> two language bindings, at least for a transitional period (i.e. until
> the next time the API changes so much that that existing scripts stop
> working, which could be quite a while).
>   

The amount of work is not limited only to the (large) areas of code in
Blender that would need to be redesigned. There is also the effort
required in the external/third-party scripts that have been written. For
example, game format importer/exporter scripts would need to be
rewritten from the ground up. Where this involves native code working
with the script - this makes a non-trivial task into an insurmountable
one for people having limited time (having to change all their C/C++
Python hooks into Lua ones). None of the work involved is
rocket-science, but it is not an incremental update either.

This ignores the social cost involved in such a transition. Aside from
those upset they need to re-implement their scripts, there are a number
Python aficionados that will rebel (and rebel HARD) against the removal
of *their* scripting language from Blender. Lua (as an example) is a
great scripting language that is small & fast, but it hasn't got the
"fan base" that Python does.

> That way when somebody asks "How do I get Blender to stop complaining
> about insecure scripts?", you can simply answer "Write your scripts in Lua."
>   

Honestly, I don't think you CAN get rid of the need for "insecure
scripts". Anything that accesses your file system (exporters of all
forms), network access (custom render farm uploaders & Verse
equivalents), etc is going to inherently be "unsafe". You will need to
trust someone for these scripts to run.

My biggest beef is simply that it is not possible to write Python
constraints & nodes in a way that doesn't allow for me to hack the
system. It is technically possible for someone to write a PyConstraint
that rifles through your hard-drive, and the language design doesn't
give you a way around this. Other smaller/tighter languages (TinyScheme,
Lua, etc) allow you to nail down the code environment such that the
scripted constraint / node simply cannot access unsafe features.

> And just to save everybody the hassle of pointing out the holes in this
> proposal, I'll play devil's advocate with myself:
>
> This feature would be nice to have, but it's probably more work than
> it's worth -- on the parts of the developers, the scripters, *and* the
> doc writers -- for something as trivial as eliminating a single click
> when you open a file.  It's also not as simple as it sounds.  Running
> all scripts in a sandbox isn't some magical panacea; a lot of thought
> will have to be put into how to deal with file/network resources and the
> like.
>   

Just as a minor addition to the above, running code in a sandbox is not
a panacea by any means. It is, however, a *requirement* for a secure
system. Without a means of sand-boxing instances of script execution -
it is impossible to secure them. So long as any snippet of script code
can import functionality from all other available modules (such as in
Python), any & all areas where script code is called becomes a security
risk.

There really are two choices:

    * Allow security holes to exist wherever script can be executed
      (with or without a user warning, but that is difficult given the
      sheer amount of Blender controlled by script now)
    * Choosing a language that allows sand-boxing of functionality /
      data access, putting effort into designing limitations at each
      interface between Blender native & scripted code, and then plough
      through the development effort & scripter backlash that would
      result from a change of language.

There is the off-chance that Python will become sandboxable in the
future, but is not on the agenda and the language semantics tend to
indicate such a task would be nigh on impossible.

-- 
Regards,

Benjamin Tolputt
Analyst Programmer