[Bf-committers] Blender security paranoia

Wed Mar 24 21:12:02 CET 2010

One setting only stores the default state for the 'Trusted' button,
The other stores if you loaded a file with 'Trusted' enabled or not.

On Wed, Mar 24, 2010 at 5:45 PM, Erwin Coumans <erwin.coumans at gmail.com> wrote:
> 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
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>

-- 
- Campbell