[Bf-committers] Do drivers have to be blocked as python scripts?

[Joshua Leung]

On another note:
IMO, despite what others have said about detecting malicious Python code to
be an intractable problem, I still believe that when you're not trying to
solve the problem of detecting whether an arbitrary piece of Python code
for arbitrary/general purposes, the problem becomes much simpler. Secondly,
if you combine this with a 3-tier security rating/permissions scheme - i.e.
0 = Trust nothing scripted at all, 1 = Allow "low risk" scripting, 2 =
Trust everything by default / allow anything to run as needed - instead of
the current all or nothing boolean switch, this would probably be
sufficient for most use cases (and the teams which do in fact use anything
beefier are probably already using or can get hold of their own private
computing resources where they can set things up to be "security free").
This solution I proposed a year ago already (
http://aligorith.blogspot.co.nz/2013/06/probabilistic-security-another-take-on.html
).

As for why I think 1-line driver expressions are a limited-enough domain
that we could successfully "lock it down" (Note that such restrictions only
apply when considering which expressions can be considered "low risk"
enough to allow them to run): Such 1-line expressions serve a very specific
purposes - that of calculating a numerical value given the driver variables
defined for that driver and optionally using builtin math functions to
operate on these. Thus, I think it's well within reason to define the
following limitations on what can/cannot be done:

1) if the expression contains attempts at multiple lines of code (i.e.
semicolons  --> this rules out doing "import nastymodule;
nastymodule.evil_stuff()"), it can't be up to any good.

2) If any identifier names used reference anything other than one of the
driver's variables or a builtin math function, that is already exceeding
the goals that a simple, well behaved, and verifiably "non malicious" code
should be doing.
   2.1) Incidentally, this should also catch any attempts to reference/call
custom functions where the really nasty stuff lives.
   2.2) We'd definitely want to look out for any obvious known weakpoints -
e.g. "exec", "eval", "import"
   2.3) Variable identifiers are something we can also verify for problems.
In fact, it's something we should be doing now if we're not doing it
already, so that users don't accidentally define identifiers they can't
actually use!

3) Any identifiers using underscores are up to no good. This rules out
digging around in Python internals to hack out to things for doing nasty
business

4) Function calls on strings are suspicious. Again the operative word here
is "low risk" - simple operations for calculating numerical values
shouldn't have a need for string manipulations. And definitely not for any
string operations where you're trying to change encoding, or perform any
kind of decryption. (For that matter, "hash-like" content is surely bad
too, but detecting that might require a bit too much data + processing for
us to use for something like this)

...

This is not a complete/conclusive list of restrictions we could apply and
check for. However, hopefully you get the idea: we're just looking to
identify what we can treat as sufficiently low risk that it really can't do
much harm. Anything "higher risk" obviously deserves human attention for
manual overriding (or running on a system where absolute security is less
of a priority).


Regards,
Joshua



On Fri, May 23, 2014 at 11:51 PM, Joshua Leung <aligorith at gmail.com> wrote:

> IIRC, we are already only blocking the drivers where Python code is used.
> To be specific, if it's of type "scripted expression" it contains Python
> code of some sort. Thus, if you can set up your drivers in a way which
> doesn't require an expression to be evaluated, you could avoid these
> problems. For example:
> - if you've just got a single variable, then just use "averaged value", or
> - if you're summing the results of two variables just use "sum",
> - if you're applying some trig function to the value or just some scale
> factor, it's perfectly fine to do by using a suitable combination of
> FModifiers and/or keyframes on the driver FCurve)
>
> Of course, this still leaves some situations unable to be resolved (i.e.
> if you need a custom function to perform some logic given the variables,
> outputting a suitable value based on those). In which case, your only
> choice there is to find some way to ensure that the security is disabled on
> that file when you go to use/render it.
>
>
> Regards,
> Joshua
>
>
>
> On Fri, May 23, 2014 at 10:26 PM, Paolo Acampora <palucam at gmail.com>wrote:
>
>> This is an issue at our studio as well, I don't see any rationale in these
>> overly security concerns, it just prevents you to work.
>>
>>
>> 2014-05-23 12:06 GMT+02:00 Vilem Novak <pildanovak at post.cz>:
>>
>> > Hello,
>> > I realize how important is the security when .blend files are
>> distributed,
>> > but I thought, is there a way to exclude drivers from the relatively new
>> > strict blocking mechanism?
>> >
>> > To me as animator, it caused allready many problems.
>> > Last is ruining several days of rendertime on a renderfarm which has
>> > scripts
>> > blocked(as is by default!). Actually, it happened to me allready several
>> > times- setting up renders, render nodes, and forgetting about some
>> drivers
>> > and the new feature.
>> > I realized so far none of the crowd-render farms for blender don't
>> support
>> > scripts on (sheepit, burp). That it of course a logical choice.
>> >
>> > So the idea is - can there be some check to determine if a driver is
>> > actually a python script? If it's using any commands, and not only
>> > numerical
>> > / logical operators? And then, could such simple drivers be enabled?
>> >
>> > It would really save my life very often. Now I have to write a script
>> that
>> > bakes all drivers before sending file to render farm...
>> >
>> > Regards
>> > Vilem
>> > _______________________________________________
>> > Bf-committers mailing list
>> > Bf-committers at blender.org
>> > http://lists.blender.org/mailman/listinfo/bf-committers
>> >
>>
>>
>>
>> --
>> Paolo Acampora, palucam at gmail.com
>> Thecnical Director at MAD entertainment, Naples (Italy)
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>
>