[Bf-committers] Blender security paranoia

[Roger Wickes]

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