[Bf-committers] Blender security paranoia

Wed Mar 24 17:35:38 CET 2010

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