[Bf-committers] Python sandbox

Wahooney wahooney at wahooney.net
Tue Mar 23 07:25:02 CET 2010


I had a thought regarding this sandbox/security business.

Wouldn't it be possible to pre-parse the python script in question and 
flag potentially harmful functions and then perhaps mark them as 
potentially malicious (kind of like a Bayesian spam filter), there will 
be some leg work to begin with, determining a list of potentially 
harmful functions, etc., but after the initial commitment it may work 
pretty well. Especially when the user is notified of the script on 
loading the .blend it can say:

    Blender has detected that the script "fuzzyDice.py" can:

        * Delete files from hard disk (potential to delete important files)
        * Save files to hard disk (potential to overwrite existing files)
        * Modify system settings (potential to disable your computer)
        * Access internet connection (potential to upload information or
        download viruses)

    Would you like this script to be activated?

Thoughts?


On 3/23/2010 3:33 AM, Leif Andersen wrote:
> That's assuming that:
>
> A.  The user knows he has malicious software on his computer.
>
> B.  Knows where it came from, and what not to install to get it to happen
> again.
>
> C.  If he has incorporate the stuff into blender itself (which is IMO too
> easy to do in the current version of blender, or at least to easy to do in
> proportion to how 'hard' it is to undo), is either willing to completely
> throw away his blender install and rebuild it, or is ready to go searching
> through all of the scripts in the .blender/scripts/ directory, or some other
> directory.
>
> I was thinking there should be some tool that would attempt to fix the
> blender install in the case of malicious software.  (I'm thinking an
> external tool would be better, as if the tool was internal, the first thing
> a malicious plugin would do, would be to find a way to disable said tool, it
> could potentially do it if it was external too, but I 'think' it  would be a
> bit harder).
>
> ~Leif Andersen
>
> ----------
> So Much to Learn, Such Little Time
> http://leifandersen.net/2010/02/03/so-much-to-learn-such-little-time/
>
>
> On Mon, Mar 22, 2010 at 19:24, Mike Belanger<mikejamesbelanger at gmail.com>wrote:
>
>    
>>> , there needs to be a way of recuperating
>>>
>>> ~Leif Andersen
>>>        
>> Load your most recent backup files, assuming your entire project has been
>> erased.
>>
>> Mike Belanger ( Mikahl )
>> www.watchmike.ca
>>      
>>>
>>> ----------
>>> So Much to Learn, Such Little Time
>>> http://leifandersen.net/2010/02/03/so-much-to-learn-such-little-time/
>>>
>>>
>>> On Mon, Mar 22, 2010 at 17:53, joe<joeedh at gmail.com>  wrote:
>>>
>>>        
>>>> Is any of this a problem in practice? What do other applications do?
>>>> Seems to me we might be making this too complicated.  Just have a
>>>> "warning: this .blend has scripts, which can be dangerous if you don't
>>>> trust the author; enable scripts?" popup on loading .blends.
>>>>
>>>> For something as complex as a digital art production package, I think
>>>> it's ok to treat .blends as if they *are* .exe's, and warn users
>>>> appropriately.
>>>>
>>>> Joe
>>>>
>>>> On Fri, Mar 19, 2010 at 2:36 AM, Campbell Barton<ideasman42 at gmail.com>
>>>> wrote:
>>>>          
>>>>> Hi Leif, probably repeating myself here but I don't understand the
>>>>> rationale for some of your suggestions.
>>>>> - Secure+Updated script installation doesn't help much since blend
>>>>> files themselves can include auto-executing drivers.
>>>>> - Separate python doesn't help with security, unless its separated in
>>>>> such a way blender can run without python at all. but in that case
>>>>> they also wont get a user interface so... don't think this helps
>>>>> either unless we move the UI back into C.
>>>>>
>>>>> Agree patching python would be a pain.
>>>>>
>>>>> This is an interesting sandbox project but I dont think blender can
>>>>> use since we would need to switch trusted/untrused context a lot but
>>>>> since the topic is raised worth mentioning.
>>>>>
>>>>> http://github.com/haypo/pysandbox/tree/master/sandbox/
>>>>> It works by writing into CPythons memory with ctypes to disable
>>>>> certain aspects of python.
>>>>>
>>>>>
>>>>> On Fri, Mar 19, 2010 at 3:55 AM, Leif Andersen
>>>>> <leif.a.andersen at gmail.com>  wrote:
>>>>>            
>>>>>> As sad as it is, it seams like your axiom Jonathan, has been true.
>>>>>> Although, that is based only on empirical evidence, not an actual
>>>>>>              
>>>> rigorous
>>>>          
>>>>>> proof.  (i.e., I would die happy if I ever found a way to make a
>>>>>>              
>>>> computer be
>>>>          
>>>>>> secure, and work seamlessly).  Some examples of this are the previous
>>>>>>              
>>>> emails
>>>>          
>>>>>> in this thread, about people who have had trouble with a locked down
>>>>>>              
>>>> python.
>>>>          
>>>>>> I still think though (like the first email in this thread), that it
>>>>>>              
>>>> would be
>>>>          
>>>>>> better to keep python separate, but still make sure that it has been
>>>>>> included on the system.  We could also have a script that checks to
>>>>>>              
>> make
>>      
>>>>>> sure it is still the latest version, in an attempt to keep it secure.
>>>>>>              
>>>> If we
>>>>          
>>>>>> include python directly into blender, that would add a severe amount
>>>>>>              
>> of
>>      
>>>>>> overhead to ensure that blender keeps up with the latest build of
>>>>>>              
>>>> python,
>>>>          
>>>>>> and even worse, if we customize it with patches, we would have to
>>>>>>              
>>>> constantly
>>>>          
>>>>>> repatch it, work that would be better spend fixing bugs/other flaws
>>>>>>              
>>>> unique
>>>>          
>>>>>> to blender/adding new features.Than again, on the other hand, we may
>>>>>>              
>>>> have to
>>>>          
>>>>>> still do the same thing if we try to customize a separate python
>>>>>>              
>> build.
>>      
>>>>>> Than again, all of this is at a very hand wavy level.  And my
>>>>>>              
>> arguments
>>      
>>>> seem
>>>>          
>>>>>> to me consist of me waving my arms, and claiming I can fly. :)
>>>>>>
>>>>>> Anyway, thank you for the support thus far everyone.
>>>>>>
>>>>>> ~Leif Andersen
>>>>>>
>>>>>> ----------
>>>>>> So Much to Learn, Such Little Time
>>>>>> http://leifandersen.net/2010/02/03/so-much-to-learn-such-little-time/
>>>>>>
>>>>>>
>>>>>> On Thu, Mar 18, 2010 at 12:43, Mike Belanger<
>>>>>>              
>>>> mikejamesbelanger at gmail.com>wrote:
>>>>          
>>>>>>              
>>>>>>> To me its not a question of how secure your pipeline is, but how
>>>>>>>                
>>>> quickly
>>>>          
>>>>>>> you
>>>>>>> can 'bounce back' after a system failure, maliciously-motived or
>>>>>>>                
>>>> otherwise.
>>>>          
>>>>>>> Yeah, you should have a firewall, passwords, admin rights etc.  But
>>>>>>>                
>>>> really,
>>>>          
>>>>>>> the best insurance policy for studio assets is automated-backup.
>>>>>>> If anything, this sandbox thing almost sounds like it could restrict
>>>>>>> backups, or make them difficult/require consent every save.  Anything
>>>>>>> discouraging/inhibiting backup is a far bigger threat, imho.
>>>>>>>
>>>>>>> A disclaimer in front of AddOns works for me.
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Mar 17, 2010 at 11:28 PM, Matt Ebb<matt at mke3.net>  wrote:
>>>>>>>
>>>>>>>                
>>>>>>>> On 18/03/2010, at 15:09 , §ĥřïñïďĥï Ŗäö wrote:
>>>>>>>>
>>>>>>>>                  
>>>>>>>>> Hi,
>>>>>>>>> This is my very first mail to this list . I am not a developer but
>>>>>>>>>                    
>>>> I
>>>>          
>>>>>>>>> thought
>>>>>>>>> i will put my 2 cents here since I felt that this discussion is a
>>>>>>>>> waste of
>>>>>>>>> time for many reasons .
>>>>>>>>> 1: +100 for Brecth and his opinion (He is perfectly right !!)
>>>>>>>>> 2: sanboxing blender will make it unusable  in large pipelines
>>>>>>>>>                    
>>>> where
>>>>          
>>>>>>>>> we need
>>>>>>>>> blender to be integrated with other softwares and also need to do a
>>>>>>>>> lot of
>>>>>>>>> automatic IO (this includes IO to databases and in  renderfarm too
>>>>>>>>> which can
>>>>>>>>> be used for other than just rendering out images )
>>>>>>>>>                    
>>>>>>>> +1 to this too. Even in 2.4* we had lots of trouble at our studio
>>>>>>>>                  
>>>> with
>>>>          
>>>>>>>> scriptlinks, pydrivers, etc being off by default. We had problems
>>>>>>>>                  
>>>> (and
>>>>          
>>>>>>>> wasted hours of work) when an artist took work home, installed a
>>>>>>>> default blender from online and worked with that - getting the file
>>>>>>>> into a state that caused lots of problems when the scripts were
>>>>>>>> working as intended. This may have happened more than once too,
>>>>>>>>                  
>> can't
>>      
>>>>>>>> remember. Similar trouble when doing some complicated things and
>>>>>>>> sending files out to other studios who weren't familiar with Blender
>>>>>>>> and this particular issue that really doesn't affect them.
>>>>>>>>
>>>>>>>> Many people who use blender don't download and open files from
>>>>>>>> strangers on the web, and I would not like to see practical
>>>>>>>>                  
>> usability
>>      
>>>>>>>> hindered just to try and give people who do the impression of
>>>>>>>>                  
>>>> security.
>>>>          
>>>>>>>> cheers,
>>>>>>>>
>>>>>>>> Matt
>>>>>>>> _______________________________________________
>>>>>>>> Bf-committers mailing list
>>>>>>>> Bf-committers at blender.org
>>>>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>>>>>>
>>>>>>>>                  
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> www.watchmike.ca
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>
>>>>          
>>> _______________________________________________
>>> 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
>    


More information about the Bf-committers mailing list