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

Fri May 23 15:06:42 CEST 2014

Another alternative for drivers specifically may be to consider moving
these away from Python, and using a dedicated expression language like
Disney's SeExpr instead. Either that, or some kind of custom DSL (probably
Pythonic or compatible with the existing Python syntax used in nature), but
with a much more limited set of valid acceptable input. The expression
validation proposal was already effectively a step in that direction,
except that we still use Python as the backend still.

In any case, we may have to consider something along these lines down the
track when we have the new depsgraph fully operational, since the GIL
issues will likely mean that we could end up with Python driver opnodes
getting backed up waiting for the thread dedicated to dealing running
anything interfacing with Python to be available.

On Sat, May 24, 2014 at 12:21 AM, Campbell Barton <ideasman42 at gmail.com>wrote:

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