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

Fri May 23 14:21:17 CEST 2014

On Fri, May 23, 2014 at 9:58 PM, Joshua Leung <aligorith at gmail.com> wrote:
> 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).

After having looked into this already, I am strongly against having
_ANY_ attempt to validate the expression based on checking the string,
these are so trivial to overcome its really not worth the effort to
attempt it, and the security it provides can be worked around after
10min looking online.

> 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
>>>
>>
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

-- 
- Campbell