[Bf-committers] Blender security paranoia

Wed Mar 24 17:45:51 CET 2010

This is becoming very confusing.

Can you explain clearly the difference between
'current trust state (user pref)' and 'default trust (global)'?

I expected at least one simple option:

1) enable autoexec of scripts

While the setting defaults to OFF, this option could be switched on/off
in the user prefs, or using a command-line argument.
Thanks,
Erwin

On 24 March 2010 09:35, Campbell Barton <ideasman42 at gmail.com> wrote:

> Setting aside the bigger issues of security, the 'Trusted' option has
> some problems.
> Basically there are 2 booleans.
> 1) default trust on/off (userpref)
> 2) current trust state on/off (global)
>
> Only 1 is made clear from the user prefs. Should probably have some
> option to set autoexec on/off for the session only.
>
> Realize this isn't communicated well so I'll try improve when I get some
> time.
>
> On Wed, Mar 24, 2010 at 5:30 PM, Roger Wickes <rogerwickes at yahoo.com>
> wrote:
> > Hey Richard,
> >
> > I would only want it on if I was running in a secured environment
> > where no/few new untrusted blend files are ever downloaded, and the
> feature
> > is desired/needed. Otherwise, off. If you want/need the feature on, AND
> you are
> > practicing unsafe downloading, then you need to practice safe downloading
> first
> > before enabling the feature.
> >
> > You don't implement security at run-time, it is implemented during
> > development and installation. We have adequate security now; no further
> measures
> > are needed. As per previous email, I demonstrated that the pipeline is
> under
> > adequate control now. If you control the factory and the pipeline that
> delivers
> > the product, product assuranceis guaranteed.
> >
> > Just to be exact, as it may be a misconception, but Blender is not run by
> a script.
> > Blender is run by the OS, which loads a blend file, and then loads the
> script.
> > I cannot see a situation where a back-end server admin is running
> blends/scripts
> > that have not been tested and verified and under SVN, so auto-run is fine
> from
> > a security standpoint, but as I pointed out, bad from a self-documenting,
> > in-the-clear-what-is-this-command-doing standpoint.
> >
> > A script can load another blend file, upon which it loses all state.
> > I think you can then have that blend file auto-execute (if enabled)
> > yet another script, but I have not and would not do so from a server
> > operations standpoint. I would simply have the first one quit, and
> > then invoke the second one via a second command line.
> > The server-side RPC Blender implementations that
> > I have writtenall explicitly load a script; auto-run is off.
> > >From a late-night debugging-why-the-heck-did-my-run-fail standpoint,
> > instead you want each unique command in the batch/cmd file
> > invoked separately, and not have this chain of weak links fail
> > somewhere in the middle. You want to know exactly which command line
> > and script failed, as each command is logically separate.
> >
> >
> > If I write a command line that executes a script, i don't need
> > another option to force execution of the script. I put the command there
> > in the first place. I told it to execute, by writing the command in the
> first
> > place, and by running the batch file...so it should do what I said to.
> >
> > To use an analogy, If I put the key in the ignition and turn it,
> > the car should not popup and ask me if I want to start the car.
> >
> > --Roger
> >
> >
> >
> >
> >
> > ________________________________
> > From: Richard Olsson <r at richardolsson.se>
> > To: bf-blender developers <bf-committers at blender.org>
> > Sent: Wed, March 24, 2010 10:04:24 AM
> > Subject: Re: [Bf-committers] Blender security paranoia
> >
> > Just a question,
> >
> > Why would you want it on? From my understanding of your e-mail, Roger,
> > you think that having a confirmation popup defeats the purpose of
> > having automatic script execution. While I do agree that it would no
> > longer be automatic, I think that the number one use case of auto-exec
> > is when blender is executed from the command-line, i.e. by a script.
> > In those situations, a simple command-line option forcing automatic
> > execution of scripts, overriding the confirmation dialog, would be the
> > way to go, I think.
> >
> > Excuse me if I misunderstood. :)
> >
> > /R
> >
> >
> > On 24 mar 2010, at 14.46, Erwin Coumans wrote:
> >
> >>>> leaving auto-execute on.
> >>
> >> You meant switching it on?
> >>
> >> As far as I know, auto-execution of python scripts when loading .blend
> >> files is turned off by default in SVN trunk.
> >>
> >> And I'm glad it is.
> >> Cheers,
> >> Erwin
> >>
> >> On Mar 24, 2010, at 6:30, Roger Wickes <rogerwickes at yahoo.com> wrote:
> >>
> >>> So, a little logic to this paranoia, and hopefully a process of
> >>> elimination. Also,
> >>> confirmation of what security we do have in place already, to make
> >>> everyone rest easier.
> >>> I agree that while however slight, the chance of having your PC
> >>> wiped by a malware script
> >>> is troubling because there is no recourse against the evildoer. That
> >>> there is money made
> >>> from it is no doubt. I discovered that I had malware sending my hard
> >>> drive contents to Russia.
> >>>
> >>> We can all agree that having a pop-up stop and force you to
> >>> confirm automatic script
> >>> executionisn't automatic script execution
> >>> and therefore defeats the purpose of the option in the first place:)
> >>>
> >>>
> >>> So if your all your scripts, like all programs installed on your PC,
> >>> are all from trusted sources,
> >>> you can enable auto-execute. Just like when I start OpenOffice, my
> >>> OS does not popup and
> >>> ask me if I want to execute OpenOffice. That would be just as
> >>> painful as the current
> >>> set of delete confirmation popups in Vista.
> >>>
> >>> The only way for a script to become part of the blender install is
> >>> for a trusted dev
> >>> to accept the patch. There has never been a case where malware patch
> >>> has been
> >>> accepted, and highly unlikely to ever be. Commit rights are only
> >>> granted to trusted devs.
> >>>
> >>> That leaves the possibility of someone hacking SVN, someone with
> >>> commit rights, or
> >>> somehow hacking into the blender.org or graphicall.org servers and
> >>> inserting a bad
> >>> script (or compiled C code) without detection. That is a server
> >>> security issue, not a sandbox problem.
> >>> There is both physical access and username/password security
> >>> protecting them.
> >>>
> >>> So that leaves someone posting a script in like BA that no one knows
> >>> and it may
> >>> or may not do something bad. In that case, you are getting a program
> >>> from an untrusted source. You can be a trusting person and just run
> >>> it, or,
> >>> since you got a new blend file from an untrusted source, you disable
> >>> auto
> >>> script
> >>> execution and open it up. Look at it, see what it does, and execute
> >>> it
> >>> if you like.
> >>>
> >>> Just as likely is someone building an evil Blender and posting the
> >>> build somewhere for people
> >>> to download. That is the general problem with software available for
> >>> the internet,
> >>> and the only way to stop that is user education, unexpired
> >>> certificates, and OS protection.
> >>>
> >>> If it is malware, community response will be immediate and vengeful,
> >>> for either Blender exe
> >>> or scripts. AFAIK scripts cannot be signed; they are text files.
> >>> Perhaps pyc files can be, but
> >>> distributing source is the practice.
> >>>
> >>> That really leaves only one remaining possibility. I think you guys
> >>> are worried about the noob
> >>> that is one of the very first to find the malware, and then proceeds
> >>> to
> >>> run un-human-readable stuff (compiled code, pyc files) on their PC,
> >>> or blindly runs source py files and does not read them or cannot
> >>> understand them,
> >>> or downloads and opens a blend file, leaving auto-execute on.
> >>>
> >>> That is the same issue as downloading any kind of
> >>> program and running it; it is impossible to protect a user from
> >>> their own stupidity.
> >>> Therefore, there is nothing further that can reasonably be done, and
> >>> no additional processes
> >>> or procedures need to be implemented.
> >>>
> >>> Therefore, the safest route is to ship Blender with auto-execute
> >>> turned off, and let the user decide
> >>> to turn it on, or instead, run scripts after reviewing them. Either
> >>> way, the process and existing
> >>> security measures guard the pipeline and the contents of the pipe.
> >>>
> >>> --Roger
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> 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
> >
> > _______________________________________________
> > 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
>