[Bf-committers] Python sandbox

[Ton Roosendaal]

Hi all,

In past discussions I had the impression that Blender's Python cannot  
be simply sandboxed because python.org doesn't cooperate with it.  
Second reason was that Blender apparently is one of the few apps  
embedding Python on such a level.

Philipp Guehring sent me these links and a suggestion:

http://sayspy.blogspot.com/2007/05/i-have-finished-securing-python.html
http://people.cs.ubc.ca/~drifty/papers/python_security.pdf
http://svn.python.org/view/python/branches/bcannon-objcap/
http://codespeak.net/pypy/dist/pypy/doc/sandbox.html
http://lackingrhoticity.blogspot.com/2009/06/python-standard-library-in-native.html

Perhaps a Google SoC project to secure Blender's Python could help here.

-Ton-


Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Python sandbox

[Benjamin Tolputt]

Ton Roosendaal wrote:
> Perhaps a Google SoC project to secure Blender's Python could help here.
>   

For people considering this, be aware that securing embedded Python
(which is what this amounts to) is a *very* large task. There is a
reason a "secure Python" isn't out & about, and it is not only because
the core (Python) developers are not interested in it. And the examples
linked to are either limited in what they sandbox (i.e. they can be
worked around), are woefully out-of-date (i.e. would require significant
work to apply to the version of Python used in Blender 2.5), or are not
really feasible for Blender due to Python being embedded (PyPy's
sandboxing).

I am not saying that it shouldn't be done, I'd just be wary of a student
being able to complete the task as a Google SoC project (through lack of
time and/or capability).

-- 
Regards,

Benjamin Tolputt
Analyst Programmer

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Python sandbox

[Campbell Barton]

On Wed, Mar 17, 2010 at 9:50 AM, Ton Roosendaal  wrote:
> Hi all,
>
> In past discussions I had the impression that Blender's Python cannot
> be simply sandboxed because python.org doesn't cooperate with it.
> Second reason was that Blender apparently is one of the few apps
> embedding Python on such a level.
>
> Philipp Guehring sent me these links and a suggestion:
>

> http://sayspy.blogspot.com/2007/05/i-have-finished-securing-python.html
This would mean we would have to distribute blender with a totally
limited python, exporters, importers wouldnt work right. it also
removes functions we're relying on for some 2.5 internals.

> http://people.cs.ubc.ca/~drifty/papers/python_security.pdf
fairly easy to work around, edited namespace can be circumvented by...
f =  [ t for t in (1).__class__.__mro__[-1].__subclasses__() if
t.__name__ == 'file'][0]('/some_file.txt', 'w')

> http://svn.python.org/view/python/branches/bcannon-objcap/
apparently proof of concept sandbox branch of python, cant get info on
this easily, looks to be 2 years old.

> http://codespeak.net/pypy/dist/pypy/doc/sandbox.html
pypy cant be used since we rely on C/Python

> http://lackingrhoticity.blogspot.com/2009/06/python-standard-library-in-native.html
Also cant be used because we need C/Python API

>
> Perhaps a Google SoC project to secure Blender's Python could help here.
>
> -Ton-

I'm not interested in this for a few reasons...

* Its a lot of work, even python guys have trouble to do this well and
there are way more python developers then blenders.
* If we had a totally sandboxed python this would limit scripts to the
point where scripts would not be able to do basic tasks (exporting,
writing files etc).
* If people start running a sandboxed blender this is a mode many
scripts need to support, a little like we had with 2.4x where we would
have to check if a fill python was installed, complain if it wasn't,
tell them to install etc.

if this goes ahead Id at least make sure it could be disabled at
compile time, but I really prefer it doesn't.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Python sandbox

[Martin Poirier]

--- On Wed, 3/17/10, Campbell Barton  wrote:

> I'm not interested in this for a few reasons...
> 
> * Its a lot of work, even python guys have trouble to do
> this well and
> there are way more python developers then blenders.

For this exact reason, I think it's totally outside the scope of GSOC.

Better people have tried and failed before.

Martin


  __
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your 
favourite sites. Download it now
http://ca.toolbar.yahoo.com.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Python sandbox

[Leif Andersen]

I was thinking of submitting a GSoC proposal about this, although just a sub
section of it, for as you point out, it is a rather large project.

It would make sense to me, to include python, as a separate module when the
user downloads blender.  It then checks to see if python has been installed
on the system, if it hasn't, it will install it, if it has, it will use it
(after checking to make sure that it hasn't been tampered with to the point
where it's unusable).

~Leif Andersen


On Wed, Mar 17, 2010 at 04:02, Campbell Barton  wrote:

> On Wed, Mar 17, 2010 at 9:50 AM, Ton Roosendaal  wrote:
> > Hi all,
> >
> > In past discussions I had the impression that Blender's Python cannot
> > be simply sandboxed because python.org doesn't cooperate with it.
> > Second reason was that Blender apparently is one of the few apps
> > embedding Python on such a level.
> >
> > Philipp Guehring sent me these links and a suggestion:
> >
>
> > http://sayspy.blogspot.com/2007/05/i-have-finished-securing-python.html
> This would mean we would have to distribute blender with a totally
> limited python, exporters, importers wouldnt work right. it also
> removes functions we're relying on for some 2.5 internals.
>
> > http://people.cs.ubc.ca/~drifty/papers/python_security.pdf
> fairly easy to work around, edited namespace can be circumvented by...
> f =  [ t for t in (1).__class__.__mro__[-1].__subclasses__() if
> t.__name__ == 'file'][0]('/some_file.txt', 'w')
>
> > http://svn.python.org/view/python/branches/bcannon-objcap/
> apparently proof of concept sandbox branch of python, cant get info on
> this easily, looks to be 2 years old.
>
> > http://codespeak.net/pypy/dist/pypy/doc/sandbox.html
> pypy cant be used since we rely on C/Python
>
> >
> http://lackingrhoticity.blogspot.com/2009/06/python-standard-library-in-native.html
> Also cant be used because we need C/Python API
>
> >
> > Perhaps a Google SoC project to secure Blender's Python could help here.
> >
> > -Ton-
>
> I'm not interested in this for a few reasons...
>
> * Its a lot of work, even python guys have trouble to do this well and
> there are way more python developers then blenders.
> * If we had a totally sandboxed python this would limit scripts to the
> point where scripts would not be able to do basic tasks (exporting,
> writing files etc).
> * If people start running a sandboxed blender this is a mode many
> scripts need to support, a little like we had with 2.4x where we would
> have to check if a fill python was installed, complain if it wasn't,
> tell them to install etc.
>
> if this goes ahead Id at least make sure it could be disabled at
> compile time, but I really prefer it doesn't.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Python sandbox

[Campbell Barton]

the problem is not so that someone would tamper with the python installation.
Its mainly that you can include malicious python code inside a blend
file in a driver or registered script.

On Wed, Mar 17, 2010 at 2:16 PM, Leif Andersen
 wrote:
> I was thinking of submitting a GSoC proposal about this, although just a sub
> section of it, for as you point out, it is a rather large project.
>
> It would make sense to me, to include python, as a separate module when the
> user downloads blender.  It then checks to see if python has been installed
> on the system, if it hasn't, it will install it, if it has, it will use it
> (after checking to make sure that it hasn't been tampered with to the point
> where it's unusable).
>
> ~Leif Andersen
>
>
> On Wed, Mar 17, 2010 at 04:02, Campbell Barton  wrote:
>
>> On Wed, Mar 17, 2010 at 9:50 AM, Ton Roosendaal  wrote:
>> > Hi all,
>> >
>> > In past discussions I had the impression that Blender's Python cannot
>> > be simply sandboxed because python.org doesn't cooperate with it.
>> > Second reason was that Blender apparently is one of the few apps
>> > embedding Python on such a level.
>> >
>> > Philipp Guehring sent me these links and a suggestion:
>> >
>>
>> > http://sayspy.blogspot.com/2007/05/i-have-finished-securing-python.html
>> This would mean we would have to distribute blender with a totally
>> limited python, exporters, importers wouldnt work right. it also
>> removes functions we're relying on for some 2.5 internals.
>>
>> > http://people.cs.ubc.ca/~drifty/papers/python_security.pdf
>> fairly easy to work around, edited namespace can be circumvented by...
>> f =  [ t for t in (1).__class__.__mro__[-1].__subclasses__() if
>> t.__name__ == 'file'][0]('/some_file.txt', 'w')
>>
>> > http://svn.python.org/view/python/branches/bcannon-objcap/
>> apparently proof of concept sandbox branch of python, cant get info on
>> this easily, looks to be 2 years old.
>>
>> > http://codespeak.net/pypy/dist/pypy/doc/sandbox.html
>> pypy cant be used since we rely on C/Python
>>
>> >
>> http://lackingrhoticity.blogspot.com/2009/06/python-standard-library-in-native.html
>> Also cant be used because we need C/Python API
>>
>> >
>> > Perhaps a Google SoC project to secure Blender's Python could help here.
>> >
>> > -Ton-
>>
>> I'm not interested in this for a few reasons...
>>
>> * Its a lot of work, even python guys have trouble to do this well and
>> there are way more python developers then blenders.
>> * If we had a totally sandboxed python this would limit scripts to the
>> point where scripts would not be able to do basic tasks (exporting,
>> writing files etc).
>> * If people start running a sandboxed blender this is a mode many
>> scripts need to support, a little like we had with 2.4x where we would
>> have to check if a fill python was installed, complain if it wasn't,
>> tell them to install etc.
>>
>> if this goes ahead Id at least make sure it could be disabled at
>> compile time, but I really prefer it doesn't.
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Python sandbox

[Ton Roosendaal]

Hi,

I am not talking about "make everything in Python run sandboxed". The  
target can be narrowed down to  a simpler task:

1) support animation scripts (drivers, constraints, fcurve mods)
2) interface scripts
3) basic import and export

If '3' or even '2' is not possible, we then can try '1' even, it might  
be useful for a total-safe blender to be used on farms, or for bug  
checks, etc. We should be aware that nearly every user won't ever code  
Python tools anyway.

I also dare to challange python.org to look into this topic again. If  
we cannot provide a decent quality and reasonable safe Blender with  
Python, we better ditch it and switch to Lua or so.

-Ton-


Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands

On 17 Mar, 2010, at 13:38, Martin Poirier wrote:

>
>
> --- On Wed, 3/17/10, Campbell Barton  wrote:
>
>> I'm not interested in this for a few reasons...
>>
>> * Its a lot of work, even python guys have trouble to do
>> this well and
>> there are way more python developers then blenders.
>
> For this exact reason, I think it's totally outside the scope of GSOC.
>
> Better people have tried and failed before.
>
> Martin
>
>
>   
> __
> Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark  
> your favourite sites. Download it now
> http://ca.toolbar.yahoo.com.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Python sandbox

[Tom M]

Ton,

on a farm blender would only have access to the folder that the admin has setup.

Any computer that has python installed has the exact same security risks.

These days, pretty much every computer has python preinstalled,
especially one used for animation.

Every animation tool has the same issue as far as i'm aware

http://securitytracker.com/alerts/2009/Nov/1023228.html

LetterRip

On Wed, Mar 17, 2010 at 8:45 AM, Ton Roosendaal  wrote:
> Hi,
>
> I am not talking about "make everything in Python run sandboxed". The
> target can be narrowed down to  a simpler task:
>
> 1) support animation scripts (drivers, constraints, fcurve mods)
> 2) interface scripts
> 3) basic import and export
>
> If '3' or even '2' is not possible, we then can try '1' even, it might
> be useful for a total-safe blender to be used on farms, or for bug
> checks, etc. We should be aware that nearly every user won't ever code
> Python tools anyway.
>
> I also dare to challange python.org to look into this topic again. If
> we cannot provide a decent quality and reasonable safe Blender with
> Python, we better ditch it and switch to Lua or so.
>
> -Ton-
>
> 
> Ton Roosendaal  Blender Foundation   t...@blender.org    www.blender.org
> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
>
> On 17 Mar, 2010, at 13:38, Martin Poirier wrote:
>
>>
>>
>> --- On Wed, 3/17/10, Campbell Barton  wrote:
>>
>>> I'm not interested in this for a few reasons...
>>>
>>> * Its a lot of work, even python guys have trouble to do
>>> this well and
>>> there are way more python developers then blenders.
>>
>> For this exact reason, I think it's totally outside the scope of GSOC.
>>
>> Better people have tried and failed before.
>>
>> Martin
>>
>>
>>
>> __
>> Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark
>> your favourite sites. Download it now
>> http://ca.toolbar.yahoo.com.
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Python sandbox

[Campbell Barton]

hehe, use lua :D, I shouldnt have suggested this at lunch today!
one day I'm told the API needs to be stabilized ASAP, the next,
suggestion to switch languages.
I cant take this seriously!

LetterRip, both blender2.5 and Maya include their own python, so it
doesn't matter if the user has python installed or not.
again, the problem isnt that blender embeds python, its that we allow
blend files to execute python automatically, effectively making
opening a *.blend file as safe as running an *.exe file on windows
from some unknown site.
(automatic execution is disabled by default but renderfarms would
probably need to enable this to be of any use).

but you are right, renderfarms should secure their environment,
sungrid did this very well. You could not even ping an external URL
from a render node.

for now I'm happy to have the 'Trusted' option on load, and focus on
keeping blender useful rather then try apply the same rules as you
would with a web-plugin.

Don't know of any developer who is interested in doing this & doubt
anything will change.

On Wed, Mar 17, 2010 at 6:46 PM, Tom M  wrote:
> Ton,
>
> on a farm blender would only have access to the folder that the admin has 
> setup.
>
> Any computer that has python installed has the exact same security risks.
>
> These days, pretty much every computer has python preinstalled,
> especially one used for animation.
>
> Every animation tool has the same issue as far as i'm aware
>
> http://securitytracker.com/alerts/2009/Nov/1023228.html
>
> LetterRip
>
> On Wed, Mar 17, 2010 at 8:45 AM, Ton Roosendaal  wrote:
>> Hi,
>>
>> I am not talking about "make everything in Python run sandboxed". The
>> target can be narrowed down to  a simpler task:
>>
>> 1) support animation scripts (drivers, constraints, fcurve mods)
>> 2) interface scripts
>> 3) basic import and export
>>
>> If '3' or even '2' is not possible, we then can try '1' even, it might
>> be useful for a total-safe blender to be used on farms, or for bug
>> checks, etc. We should be aware that nearly every user won't ever code
>> Python tools anyway.
>>
>> I also dare to challange python.org to look into this topic again. If
>> we cannot provide a decent quality and reasonable safe Blender with
>> Python, we better ditch it and switch to Lua or so.
>>
>> -Ton-
>>
>> 
>> Ton Roosendaal  Blender Foundation   t...@blender.org    www.blender.org
>> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
>>
>> On 17 Mar, 2010, at 13:38, Martin Poirier wrote:
>>
>>>
>>>
>>> --- On Wed, 3/17/10, Campbell Barton  wrote:
>>>
 I'm not interested in this for a few reasons...

 * Its a lot of work, even python guys have trouble to do
 this well and
 there are way more python developers then blenders.
>>>
>>> For this exact reason, I think it's totally outside the scope of GSOC.
>>>
>>> Better people have tried and failed before.
>>>
>>> Martin
>>>
>>>
>>>
>>> __
>>> Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark
>>> your favourite sites. Download it now
>>> http://ca.toolbar.yahoo.com.
>>> ___
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Python sandbox

[Richard Olsson]

Hi,

I'm new to the list, but wanted to add my thoughts. I've used the  
blender 2.49 py api a lot in my work as a Flash developer specialized  
at 3D, mostly writing custom exporters, and am currently working on  
the 2.50 api and scripts.

I agree with Campbell that there's really no problem in allowing  
python code that's invoked by blender to utilize the full capabilities  
of python. The issue lies in executing said code without requiring the  
user to explicitly initiate it.

I think that if anything, a warning should be added when new scripts  
are installed, or when add-ons are activated, stating that "By  
installing this script you allow it to execute code that may harm your  
system", or similar.

The problem of course lies in operators' register() methods, for  
example, which could as far as I know contain any code, right? Maybe  
they should be swapped for a module-wide list/tuple containing the  
operator classes, avoiding the risk of unknown code being executed at  
startup.


Please excuse any stupid comments caused by me not having followed the  
thread from the start. :)


Cheers
/R



On 17 mar 2010, at 19.08, Campbell Barton wrote:

> hehe, use lua :D, I shouldnt have suggested this at lunch today!
> one day I'm told the API needs to be stabilized ASAP, the next,
> suggestion to switch languages.
> I cant take this seriously!
>
> LetterRip, both blender2.5 and Maya include their own python, so it
> doesn't matter if the user has python installed or not.
> again, the problem isnt that blender embeds python, its that we allow
> blend files to execute python automatically, effectively making
> opening a *.blend file as safe as running an *.exe file on windows
> from some unknown site.
> (automatic execution is disabled by default but renderfarms would
> probably need to enable this to be of any use).
>
> but you are right, renderfarms should secure their environment,
> sungrid did this very well. You could not even ping an external URL
> from a render node.
>
> for now I'm happy to have the 'Trusted' option on load, and focus on
> keeping blender useful rather then try apply the same rules as you
> would with a web-plugin.
>
> Don't know of any developer who is interested in doing this & doubt
> anything will change.
>
> On Wed, Mar 17, 2010 at 6:46 PM, Tom M  wrote:
>> Ton,
>>
>> on a farm blender would only have access to the folder that the  
>> admin has setup.
>>
>> Any computer that has python installed has the exact same security  
>> risks.
>>
>> These days, pretty much every computer has python preinstalled,
>> especially one used for animation.
>>
>> Every animation tool has the same issue as far as i'm aware
>>
>> http://securitytracker.com/alerts/2009/Nov/1023228.html
>>
>> LetterRip
>>
>> On Wed, Mar 17, 2010 at 8:45 AM, Ton Roosendaal   
>> wrote:
>>> Hi,
>>>
>>> I am not talking about "make everything in Python run sandboxed".  
>>> The
>>> target can be narrowed down to  a simpler task:
>>>
>>> 1) support animation scripts (drivers, constraints, fcurve mods)
>>> 2) interface scripts
>>> 3) basic import and export
>>>
>>> If '3' or even '2' is not possible, we then can try '1' even, it  
>>> might
>>> be useful for a total-safe blender to be used on farms, or for bug
>>> checks, etc. We should be aware that nearly every user won't ever  
>>> code
>>> Python tools anyway.
>>>
>>> I also dare to challange python.org to look into this topic again.  
>>> If
>>> we cannot provide a decent quality and reasonable safe Blender with
>>> Python, we better ditch it and switch to Lua or so.
>>>
>>> -Ton-
>>>
>>> 
>>> Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
>>> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The  
>>> Netherlands
>>>
>>> On 17 Mar, 2010, at 13:38, Martin Poirier wrote:
>>>


 --- On Wed, 3/17/10, Campbell Barton  wrote:

> I'm not interested in this for a few reasons...
>
> * Its a lot of work, even python guys have trouble to do
> this well and
> there are way more python developers then blenders.

 For this exact reason, I think it's totally outside the scope of  
 GSOC.

 Better people have tried and failed before.

 Martin



 __
 Yahoo! Canada Toolbar: Search from anywhere on the web, and  
 bookmark
 your favourite sites. Download it now
 http://ca.toolbar.yahoo.com.
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
>>>
>>> ___
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>
>> ___
>> Bf-committers mailing li

Re: [Bf-committers] Python sandbox

[Campbell Barton]

We can ignore script installation issues or anything related to
blenders API's...
if you can run a line of python (such as a pydriver) among other evil
things you can remove the users home dir.

eg, valid one line driver which wont raise and error.
 0.0 if __import__("shutil").rmtree(__import__("os").getenv("HOME")) else 0.0

But I think we could have a more constructive discussion if we think
of a good reply to someone building a renderfarm.
(ok, only solves the problem in one case but still useful)

This might end up being that they just need to secure their systems,
but we could also include tools with blender to bake drivers in one
step so renderfarms can disable python and still render users
animations.

On Wed, Mar 17, 2010 at 7:30 PM, Richard Olsson  wrote:
> Hi,
>
> I'm new to the list, but wanted to add my thoughts. I've used the
> blender 2.49 py api a lot in my work as a Flash developer specialized
> at 3D, mostly writing custom exporters, and am currently working on
> the 2.50 api and scripts.
>
> I agree with Campbell that there's really no problem in allowing
> python code that's invoked by blender to utilize the full capabilities
> of python. The issue lies in executing said code without requiring the
> user to explicitly initiate it.
>
> I think that if anything, a warning should be added when new scripts
> are installed, or when add-ons are activated, stating that "By
> installing this script you allow it to execute code that may harm your
> system", or similar.
>
> The problem of course lies in operators' register() methods, for
> example, which could as far as I know contain any code, right? Maybe
> they should be swapped for a module-wide list/tuple containing the
> operator classes, avoiding the risk of unknown code being executed at
> startup.
>
>
> Please excuse any stupid comments caused by me not having followed the
> thread from the start. :)
>
>
> Cheers
> /R
>
>
>
> On 17 mar 2010, at 19.08, Campbell Barton wrote:
>
>> hehe, use lua :D, I shouldnt have suggested this at lunch today!
>> one day I'm told the API needs to be stabilized ASAP, the next,
>> suggestion to switch languages.
>> I cant take this seriously!
>>
>> LetterRip, both blender2.5 and Maya include their own python, so it
>> doesn't matter if the user has python installed or not.
>> again, the problem isnt that blender embeds python, its that we allow
>> blend files to execute python automatically, effectively making
>> opening a *.blend file as safe as running an *.exe file on windows
>> from some unknown site.
>> (automatic execution is disabled by default but renderfarms would
>> probably need to enable this to be of any use).
>>
>> but you are right, renderfarms should secure their environment,
>> sungrid did this very well. You could not even ping an external URL
>> from a render node.
>>
>> for now I'm happy to have the 'Trusted' option on load, and focus on
>> keeping blender useful rather then try apply the same rules as you
>> would with a web-plugin.
>>
>> Don't know of any developer who is interested in doing this & doubt
>> anything will change.
>>
>> On Wed, Mar 17, 2010 at 6:46 PM, Tom M  wrote:
>>> Ton,
>>>
>>> on a farm blender would only have access to the folder that the
>>> admin has setup.
>>>
>>> Any computer that has python installed has the exact same security
>>> risks.
>>>
>>> These days, pretty much every computer has python preinstalled,
>>> especially one used for animation.
>>>
>>> Every animation tool has the same issue as far as i'm aware
>>>
>>> http://securitytracker.com/alerts/2009/Nov/1023228.html
>>>
>>> LetterRip
>>>
>>> On Wed, Mar 17, 2010 at 8:45 AM, Ton Roosendaal 
>>> wrote:
 Hi,

 I am not talking about "make everything in Python run sandboxed".
 The
 target can be narrowed down to  a simpler task:

 1) support animation scripts (drivers, constraints, fcurve mods)
 2) interface scripts
 3) basic import and export

 If '3' or even '2' is not possible, we then can try '1' even, it
 might
 be useful for a total-safe blender to be used on farms, or for bug
 checks, etc. We should be aware that nearly every user won't ever
 code
 Python tools anyway.

 I also dare to challange python.org to look into this topic again.
 If
 we cannot provide a decent quality and reasonable safe Blender with
 Python, we better ditch it and switch to Lua or so.

 -Ton-

 
 Ton Roosendaal  Blender Foundation   t...@blender.org    www.blender.org
 Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The
 Netherlands

 On 17 Mar, 2010, at 13:38, Martin Poirier wrote:

>
>
> --- On Wed, 3/17/10, Campbell Barton  wrote:
>
>> I'm not interested in this for a few reasons...
>>
>> * Its a lot of work, even python guys have trouble to do
>> this well and
>> there are way more

Re: [Bf-committers] Python sandbox

[jonathan d p ferguson]

hi.


I feel that I must raise the issue of *trust* again. It is extremely  
relevant to this issue, and many others now facing many FOSS  
communities, particularly blender.

The problem is running *untrusted* code. The trust in this case,  
really comes down to trusting the script's author.

Perhaps it is time to implement a robust trust model.

Implementing a robust trust model does not require a switch of  
languages, nor does it require crippling python. What it *does*  
require is a robust, authenticated trust model that cannot be spoofed.  
A central authority is one such model, if very carefully created  
(think Certificate Authority). The Web of Trust is another, and one  
that I will articulate here for those unfamiliar with it. A Web of  
Trust model is usually more robust than a central authority model, as  
it is not subject to a single point of failure like the Certificate  
Authority model. GnuPG (aka PGP)'s Web of Trust model is the most  
robust I've seen.

Perhaps a GSoC proposal to investigate this, and possibly implement a  
Web of Trust model? (This isn't a proposal, yet, but it could develop  
into one. I am happy to help advise a student for the GSoC--- if there  
is sufficient interest by the community.)






Here's how I imagine a Web of Trust would apply to the "python  
scripts" problem in Blender:

The basic idea in a Web of Trust is that blender users and developers  
will have GnuPG keys. Already trusted content will run automatically--- 
based on some trust-threshold setting (this is built into GnuPG). The  
bf-keys will be the most trusted--- as all developers and many users  
will sign those keys. Content (read, programs) will be  
cryptographically signed by the content creators. If the trust values  
of those creators exceed the trust threshold set by the end user, then  
that content will be able to run, otherwise, the default action is to  
prevent the script from running. Eventually, all trusted scripts will  
run without a prompt.

Again, the most accessible, and widely deployed trust model I know of  
is the Web of Trust--- which I raised in my previous email about the  
new Python script approval process. This model uses GnuPG keys and the  
social networks of users who authenticate each other. The model  
applies to the development, and distribution phases of the blender  
life-cycle.



Here's how the basic user-story would go:

Goal: Download an untrusted script, written by someone you have not  
encountered before, and run it.

Requirements: For the script to run, you must trust it. That trust  
will be expressed by the trust value in the Web of Trust model, you,  
as you, the end user, set. You have a GnuPG key. The script-author  
also has a GnuPG key. The author signed her script with her key.  
Blender knows where your GnuPG key is. For convenience, both keys are  
in a centralized key-server. Blender will automatically fetch her key,  
to verify that she did, in fact, sign the script (this process is  
called validation).

Actions: Download her script. If enough of your *trusted friends*  
trust the script-author, then, depending on your trust-settings, the  
script may be run. If not, then you will be prompted to: 1. run the  
script (with an appropriate warning*), and/or 2. accept the author's  
key for future trust. 3. One may even opt to sign the developer's key  
later on if she proves to be trustworthy. After passing these  
authentication, and authorization stages, the script will run (be  
given access).

*Please note, the default action is NOT to run. It is imperative to  
make sure that no denial-of-service prompting will occur. Users must  
*explicitly* allow the script to run.

These operations could be integrated into blender, bringing blender  
into the social application sphere--- with a robust trust model for  
developers and users alike. While Blender would not be the first  
project to use the web-of-trust model, it will be the first  
application with this level of atomic integration. A good model to  
evaluate is that used by Debian and Ubuntu. Both of those  
distributions employ a Web-of-Trust to protect the integrity of the  
distribution, and to discourage malware. That is the goal here also,  
as blender will be a distribution of tools, as opposed to a "single- 
application."



Possible changes to the blender project (this is just an example  
set--- to show the idea):

* Blender developers will all have GnuPG keys, and (depending on the  
outcome of decisions about the process) they will all sign a "bf-keys"  
GnuPG keyring and/or key depending. Think code-signing key.
* Blender executables, and releases will be signed with said bf-keys  
key. This key will be *the most trusted* because many developers and  
users will trust it (either by signing the key, or accepting it).
* Blender will integrate the GnuPG libraries as appropriate (GPGME for  
example).
* Blender's User Interface will expose appropriate trust mechanisms  
for al

Re: [Bf-committers] Python sandbox

[Leif Andersen]

I really like Jonathan's idea.  Perhaps some sort of distributes/crowd
sourced 'plugin center' for blender, that relies on a web of trust.  I think
that is a great idea, and unless the community thinks it's a horrible idea,
I will submit a GSoC proposal on it.

~Leif Andersen

--
So Much to Learn, Such Little Time
http://leifandersen.net/2010/02/03/so-much-to-learn-such-little-time/


On Wed, Mar 17, 2010 at 16:59, jonathan d p ferguson wrote:

> hi.
>
>
> I feel that I must raise the issue of *trust* again. It is extremely
> relevant to this issue, and many others now facing many FOSS
> communities, particularly blender.
>
> The problem is running *untrusted* code. The trust in this case,
> really comes down to trusting the script's author.
>
> Perhaps it is time to implement a robust trust model.
>
> Implementing a robust trust model does not require a switch of
> languages, nor does it require crippling python. What it *does*
> require is a robust, authenticated trust model that cannot be spoofed.
> A central authority is one such model, if very carefully created
> (think Certificate Authority). The Web of Trust is another, and one
> that I will articulate here for those unfamiliar with it. A Web of
> Trust model is usually more robust than a central authority model, as
> it is not subject to a single point of failure like the Certificate
> Authority model. GnuPG (aka PGP)'s Web of Trust model is the most
> robust I've seen.
>
> Perhaps a GSoC proposal to investigate this, and possibly implement a
> Web of Trust model? (This isn't a proposal, yet, but it could develop
> into one. I am happy to help advise a student for the GSoC--- if there
> is sufficient interest by the community.)
>
>
>
>
>
>
> Here's how I imagine a Web of Trust would apply to the "python
> scripts" problem in Blender:
>
> The basic idea in a Web of Trust is that blender users and developers
> will have GnuPG keys. Already trusted content will run automatically---
> based on some trust-threshold setting (this is built into GnuPG). The
> bf-keys will be the most trusted--- as all developers and many users
> will sign those keys. Content (read, programs) will be
> cryptographically signed by the content creators. If the trust values
> of those creators exceed the trust threshold set by the end user, then
> that content will be able to run, otherwise, the default action is to
> prevent the script from running. Eventually, all trusted scripts will
> run without a prompt.
>
> Again, the most accessible, and widely deployed trust model I know of
> is the Web of Trust--- which I raised in my previous email about the
> new Python script approval process. This model uses GnuPG keys and the
> social networks of users who authenticate each other. The model
> applies to the development, and distribution phases of the blender
> life-cycle.
>
>
>
> Here's how the basic user-story would go:
>
> Goal: Download an untrusted script, written by someone you have not
> encountered before, and run it.
>
> Requirements: For the script to run, you must trust it. That trust
> will be expressed by the trust value in the Web of Trust model, you,
> as you, the end user, set. You have a GnuPG key. The script-author
> also has a GnuPG key. The author signed her script with her key.
> Blender knows where your GnuPG key is. For convenience, both keys are
> in a centralized key-server. Blender will automatically fetch her key,
> to verify that she did, in fact, sign the script (this process is
> called validation).
>
> Actions: Download her script. If enough of your *trusted friends*
> trust the script-author, then, depending on your trust-settings, the
> script may be run. If not, then you will be prompted to: 1. run the
> script (with an appropriate warning*), and/or 2. accept the author's
> key for future trust. 3. One may even opt to sign the developer's key
> later on if she proves to be trustworthy. After passing these
> authentication, and authorization stages, the script will run (be
> given access).
>
> *Please note, the default action is NOT to run. It is imperative to
> make sure that no denial-of-service prompting will occur. Users must
> *explicitly* allow the script to run.
>
> These operations could be integrated into blender, bringing blender
> into the social application sphere--- with a robust trust model for
> developers and users alike. While Blender would not be the first
> project to use the web-of-trust model, it will be the first
> application with this level of atomic integration. A good model to
> evaluate is that used by Debian and Ubuntu. Both of those
> distributions employ a Web-of-Trust to protect the integrity of the
> distribution, and to discourage malware. That is the goal here also,
> as blender will be a distribution of tools, as opposed to a "single-
> application."
>
>
>
> Possible changes to the blender project (this is just an example
> set--- to show the idea):
>
> * Blender developers will all have GnuPG keys, and (

Re: [Bf-committers] Python sandbox

[Brecht Van Lommel]

Hi,

I don't think I'm bringing up anything new here but would like to
point out some things.

First is that there is a difference between python scripts, one
category is scripts to extend blender like exporters. These
fundamentally can't run inside a sandbox since they need to access
files. Some can but it's not worth making the distinction in my
opinion. I'm not at all worried about this case really, if you
download extensions, plugins, I think people understand these are
potentially unsafe. The bf-extensions repository should work well as a
place to get things officially reviewed, and personally I don't think
it's necessary to do anything more complicated, especially not if it
is something that users have to deal with.

The real problem is loading .blend files, which users may not know is
unsafe. Running scripts is now disabled by default in Blender 2.5, and
users must specify explicitly that they trust the .blend file. This
replaces the security problem with a usability problem, i.e. loading
your own .blend files or e.g. a scripted rig downloaded from the
internet is less convenient this way. We could try to improve this
still, by warning more clearly if there are scripts and perhaps
letting Blender remember which .blend files are trusted.

To completely avoid this problem (which I think is really a usability
problem with scripts disabled by default), we could try to sandbox
such scripts included in .blend files. Besides the fact that python is
difficult, by accessing Blender data and operators you can still do
the same damage though it's a more complicated. We could try to secure
this but it is really difficult, in projects that really care about
this (e.g. firefox) security holes are still found, and I don't think
Blender developers will really want to invest time to makes this safe.
It's also not something you solve once, every Blender feature is a
potential security problem. For basic expressions for drivers you
could possibly lock down pretty much everything and still have them
work. For more advanced scripts making e.g. panels or drawing in the
3d view, this will not work, and more advanced rigs will take
advantage of the extensibility of 2.5.

To sum up my opinion, sandboxing is very hard and not something we can
solve once, it requires continuous attention, so let's not even try
it. Instead, the install addon operator should warn about security
problems, and loading a .blend file with scripts should become easier
for users.

Brecht.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Python sandbox

[Benjamin Tolputt]

Leif Andersen wrote:
> I really like Jonathan's idea.  Perhaps some sort of distributes/crowd
> sourced 'plugin center' for blender, that relies on a web of trust.  I think
> that is a great idea, and unless the community thinks it's a horrible idea,
> I will submit a GSoC proposal on it.
>   

I cannot speak for the community, but my thoughts are that a "web of
trust" misses the point. Trust systems work so long as one assumes that
the participants are going to be a somewhat insular community. This
works well for code, emails, and the like but artists? We're doing our
best to shield them from the technicalities on the one hand, but
requiring them to be part of a trust network just to share files?

We would also now require users to connect online to open new files (in
order to verify the trust chain). And any trust network would need to be
maintained. And all because the chosen language is, by default,
unsecure. What happens when a previously trusted person goes rogue (or
more likely, someone hacks their machine and uses their credentials) to
create a malicious .blend file? How does one revoke this trust across a
network of machines without requiring them to connect to a central server?

The problem is, quite frankly,  the language/platform used and the
solution resides in either fixing the language or replacing it.
Overlaying trust networks on the basic use of Blender is just overly
complicating the application and doesn't really get rid of the problem -
that being a Python expression for driving a rig can easily wipe your
hard drive. By the time you realise the person signing the file should
not be trusted - the damage has been done.

-- 
Regards,

Benjamin Tolputt
Analyst Programmer

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Python sandbox

[Benjamin Tolputt]

Brecht Van Lommel wrote:
> First is that there is a difference between python scripts, one
> category is scripts to extend blender like exporters. These
> fundamentally can't run inside a sandbox since they need to access
> files. 
>   

This is, indeed, not new and I know it has been mentioned multiple times
in this "thread" given I've mentioned it more than once :)

The fact of the matter is exporters/importers need to access the file
system to work. That is basically the definition of their existence -
moving data between Blender's internal state to the file system & back.

> To sum up my opinion, sandboxing is very hard and not something we can
> solve once, it requires continuous attention, so let's not even try
> it. Instead, the install addon operator should warn about security
> problems, and loading a .blend file with scripts should become easier
> for users.
>   

Actually, sand-boxing scripts is quite easy provided you use a platform
that supports it. Python currently does not support this so the task
seems insurmountable; but only so long as you look through the Python
lens. It is quite simple to sandbox applications using Lua - simply
don't give them access to the unsecure functionality. If you don't want
the user reading/writing files not explicitly handed to them? Then don't
give them access to the "io" library (by excluding it from the VM's
initialisation). Don't want to give the person access to the operating
system, don't add the "os" module to those accessible by the VM. And so on.

Python has an unofficial design foundation that developers should
"extend Python" with their application rather than "embed Python" into
their application. As such, Python exposes everything one would need in
an application platform - file access, network sockets, operating system
calls, etc. Unlike Java (another extend vs embed platform), this was all
done on the assumption that you wouldn't WANT to limit the virtual
machine running Python from accessing these resources. Other parts of
the system get written on the (valid) assumption the unsecure
functionality will be exposed and so removing file/socket access & the
like becomes an exercise in "hunt the bug" throughout the entire Python
platform/standard library.

Other languages / virtual machines are designed with an "embedding"
mentality. You need to explicitly expose the functionality you want to
use in a script to the virtual machine. Most of the good ones come with
standard libraries to access these features but they can be disabled
with the commenting of a handful of lines at most. In addition, the best
embedded virtual machines give you explicit hooks (or outline the
internal code to change) enabling the end user to override the memory
allocation & CPU usage (i.e. byte-code instructions run without break).

Also, the Firefox analogy is a good one to use. There are two levels of
scripts Firefox runs - the "plugin scripts" which can access your
hard-drive, use Firefox services to retrieve data online, etc and then
there are "content scripts" - the JavaScript that gets run in your
browser when you navigate to a site using it. Unless some explicit
exception is in place - the JavaScript from the web-pages cannot access
the content of your hard drive because it was never given access to the
classes/functions that allow this. However the plugin scripts DO have
the capability of accessing these services because the JavaScript VM
adds classes/functions to allow this. The browser downloaded scripts are
"sand-boxed" like we would desire our scripted constraints & rig drivers
to be whereas the Firefox add-ons are given more functionality like we
desire our import/export scripts to be. Where bugs in this show up, it
is generally not so much to do with the sand-boxing as memory overruns &
the like that are a separate problem Blender would have to deal with anyway.

In summary, sand-boxing is not hard provided you use the right platform
nor does it need "continuous attention". You set up the trusted &
untrusted virtual machines with the functionality they are allowed to
have and that is all. Adding "exceptions" is easy enough, flag the
scripted constraint / driver as requiring access to the file system, add
the file system functionality to the scene VM and raise a warning when
opening it.

-- 
Regards,

Benjamin Tolputt
Analyst Programmer

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Python sandbox

[Brecht Van Lommel]

Hi,

On Thu, Mar 18, 2010 at 1:51 AM, Benjamin Tolputt
 wrote:
>> To sum up my opinion, sandboxing is very hard and not something we can
>> solve once, it requires continuous attention, so let's not even try
>> it. Instead, the install addon operator should warn about security
>> problems, and loading a .blend file with scripts should become easier
>> for users.
>>
>
> Actually, sand-boxing scripts is quite easy provided you use a platform
> that supports it. Python currently does not support this so the task
> seems insurmountable; but only so long as you look through the Python
> lens. It is quite simple to sandbox applications using Lua - simply
> don't give them access to the unsecure functionality. If you don't want
> the user reading/writing files not explicitly handed to them? Then don't
> give them access to the "io" library (by excluding it from the VM's
> initialisation). Don't want to give the person access to the operating
> system, don't add the "os" module to those accessible by the VM. And so on.

I don't think making the Blender API safe is easy. Some examples of
things that could be exploited:
* .blend/image/sound save operators
* render animation operator
* physics systems point caches writing to disk
* open file browser + run file delete operator
* binding keymap or buttons to an operator
* compositing file output node
* register operator to override .obj exporter

And then there are of course the more complicated ones, memory
corruption, buffer overruns, etc now become security issues. I bet you
can find dozens of indirect an non-obvious ways to do damage. Now, you
can try to figure out all those cases and add checks for them, but
doing this well is really hard. Security issues in web browsers don't
happen because they forgot to disable access to the IO module. And as
new features are added to Blender this does require continuous
attention.

Brecht.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Python sandbox

[Leif Andersen]

>
> I cannot speak for the community, but my thoughts are that a "web of
> trust" misses the point. Trust systems work so long as one assumes that
> the participants are going to be a somewhat insular community. This
> works well for code, emails, and the like but artists? We're doing
>  incredibly our

 best to shield them from the technicalities on the one hand, but
> requiring them to be part of a trust network just to share files?
>

True, while I don't completely agree with the exact method Jonathon is
proposing, I still think the idea of a plugin center of sorts is a good
idea.  It seams like blender prides itself on having an incredibly small
system requirements, and download size for what it does (after all, other 3d
modeling programs takes up hundreds of MB, if not several GB of data, and it
also runs on relatively little ram (for small enough projects anyway)).  If
all of the main plugins were stored in the blender file, with blender 2.5+
allowing for very modular programing, that could get unneeded large.  On the
other hand, if the plugins are stored in a location buried deep within the
blender website/wiki/other blender community page, the user would have to
open their browser, go to that page, find the script they wanted, download
it, either put it in a plugins directory, or run a script to automatically
put it in the directory (both of which are going to be incredibly insecure,
no matter how much you sandbox python (well, unless you limited it to only
allow for a few functions that don't use indirection in any way shape or
form)), or the user would open up blender, click on an add plugin button, a
security warning would pop up, the user would then locate the file on his
hard drive, and the plugin would get added.  You could also potentially have
multiple levels of access, for example, a plugin that only allows for a
customized window wouldn't need access to the hard drive, only to a few
'button and menu objects', although, passing in the context could provide
major security flaws.

On the other hand, there could be a button in blender, that opens up a
dialog, which contains a software center, containing all of the pseudo
social aspects that plugin managers (such as the one in the wordpress
software), has.  Also, you could potentially either 'crowd source' (I hate
that phrase, if anyone has anything better, please tell me) the plugins (the
best way would likely to be to only allow for apps who's source code is
viewable, and/or to have a digg like review system), or, the default could
only be to show plugins that the blender foundation has personally verified
(which I think isn't necessarily the best way, but it would work for a few
plugins).  The user then clicks on the icon, sees a security warning, with a
link showing how the plugin center approves software, and then they can
download it.  Alternatively, if the user did find a plugin that they liked
on an external website, they could add it (either by a seperit button
outside of the center, or by an 'add from external link' button, this would
of course, pop up with a more fervent security warning.

~Leif Andersen

--
So Much to Learn, Such Little Time
http://leifandersen.net/2010/02/03/so-much-to-learn-such-little-time/


On Wed, Mar 17, 2010 at 19:45, Brecht Van Lommel  wrote:

> Hi,
>
> On Thu, Mar 18, 2010 at 1:51 AM, Benjamin Tolputt
>  wrote:
> >> To sum up my opinion, sandboxing is very hard and not something we can
> >> solve once, it requires continuous attention, so let's not even try
> >> it. Instead, the install addon operator should warn about security
> >> problems, and loading a .blend file with scripts should become easier
> >> for users.
> >>
> >
> > Actually, sand-boxing scripts is quite easy provided you use a platform
> > that supports it. Python currently does not support this so the task
> > seems insurmountable; but only so long as you look through the Python
> > lens. It is quite simple to sandbox applications using Lua - simply
> > don't give them access to the unsecure functionality. If you don't want
> > the user reading/writing files not explicitly handed to them? Then don't
> > give them access to the "io" library (by excluding it from the VM's
> > initialisation). Don't want to give the person access to the operating
> > system, don't add the "os" module to those accessible by the VM. And so
> on.
>
> I don't think making the Blender API safe is easy. Some examples of
> things that could be exploited:
> * .blend/image/sound save operators
> * render animation operator
> * physics systems point caches writing to disk
> * open file browser + run file delete operator
> * binding keymap or buttons to an operator
> * compositing file output node
> * register operator to override .obj exporter
>
> And then there are of course the more complicated ones, memory
> corruption, buffer overruns, etc now become security issues. I bet you
> can find dozens of indirect an non-obvious ways to do damage. Now, you
> can tr

Re: [Bf-committers] Python sandbox

[Benjamin Tolputt]

Leif Andersen wrote:
> True, while I don't completely agree with the exact method Jonathon is
> proposing, I still think the idea of a plugin center of sorts is a good
> idea.

I have no issues with this at all. The plugins that come with Blender
are trusted by default and a central location to find other plugins
(rated for trust or otherwise) is a good thing. Much the same way
Firefox has it's site for add-ons, being able to register a plugin for
exporting to Ogre (as an example) and it being easily found by Blender
users is a Good Thing(tm).

The benefits of this are orthogonal to securing Blender (because scene
files are excluded and that is where the main danger lies) but it is a
good idea nonetheless, deserving perhaps to be considered outside this
discussion (to prevent the debate about one idea discolouring the other)?

-- 
Regards,

Benjamin Tolputt
Analyst Programmer

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Python sandbox

[jonathan d p ferguson]

hi.

First off, Leif, thanks for volunteering to study this set of ideas!  
And thanks to all for the excellent comments and opinions expressed so  
far!

I would like to forward what I've been calling my axiom of usability  
in computer security for the last 10 years or so:

"Computer security is inversely related to the usability of a system.  
The more secure, the less usable. The less secure, the more likely it  
is to be usable."

Good computer security, these days, has become a usability problem,  
because computer security is *complicated* and users don't like  
*complicated.* Yet as the malware industry (estimated at $1+ billion  
and growing) continues to grow, the exploits will only become more and  
more sophisticated. End users must be educated, and that's a big  
reason why I'm suggesting a Web of Trust model. That model can be  
limited to any population we wish.

I agree that it should Just Work. Seeing the success of the Web of  
Trust in the Debian and Ubuntu operating systems, it is quite evident  
to me that asking for a clear chain of cryptographically verifiable  
identity through a Web of Trust model, is not only doable, but when  
carefully implemented, will protect end users from malicious code, in  
any language, leaving the blender coders free to make system changes  
as they see fit. Blender is becoming a *distribution.* It is likely to  
rapidly be exiting the realm of an "application" in short order, as  
Leif points out.

Blender is GPL, and that is a very good thing for security, as it  
allows for peer review. AFAIK, Python scripts written to run in  
blender will also be required to be GPL. Concerned users can read over  
the code prior to execution. The injection of a "do you trust X?"  
dialog only solves half of the problem, however. The other half is  
that of verifying the identity of X. Creating a central distribution  
system is also a fine thing--- but it does not address the problem of  
trust fully--- and requires time on the behalf of those who are  
charged with the task of vetting what is allowed in that "plugin  
repository."

I am fully in support of a centralized, or decentralized web of plugin  
repositories. It follows, to me, that each extension or plugin or file  
should be independently verifiable, however. That verification should  
*become* automatic for 99% of the cases in the Web of Trust model,  
reducing the requirement of intervention on the behalf of the user.  
Firefox doesn't actually offer any trust metric at all. End users just  
"use the plugins." Further, Firefox is *fundamentally* different in  
form, and function from blender--- it is not a content creation  
tool--- it is a content browser. While one *can* get a plugin to  
create content, that is not, and was not, the primary purpose. That's  
an important distinction. Blender does not have the same luxury of  
limiting script capability.

The goal is to prevent someone from executing a malicious bit of  
software.

This is a very very challenging problem. Computer security experts  
have spent decades and billions of (government) dollars trying to  
arrive at perfect solutions to this problem. As far as I know, no such  
*perfect* solutions exist--- but many solutions do exist, and the  
appropriateness of the solution depends on the use case. Sandboxing (a  
form of mandatory access control) and a GnuPG Web of Trust (whether  
centralized or decentralized), are potentially good solutions--- but  
we need to evaluate the merits of each for the blender community. I've  
"been there, done that" with the sandbox in currently shipping  
commercial software, and don't actually believe that it is the best  
solution for the blender community, especially given how we in that  
community work, and share files.

I believe that blender's community is growing, and that it is a  
cutting-edge community. Many members of the blender community already  
know and trust each other, so making a Web of Trust will only serve to  
strengthen the blender community. Finally, I point out that a Web of  
Trust is not inherently restricted to closed communities at all. Most  
individuals will only need to trust a few sources, the most trusted  
being the centralized source.

Blender, is itself, a very cutting-edge system, and the tight  
integration of python in blender is part of what makes it so cutting  
edge. Bringing blender towards a socially verifiable web of trust,  
will go farther than any other "application" that I know of, to  
validate "plugins" or "extensions" or .blend files.

On Mar 17, 2010, at 9:45 PM, Brecht Van Lommel wrote:

> Hi,
>
> On Thu, Mar 18, 2010 at 1:51 AM, Benjamin Tolputt
>  wrote:
>>> To sum up my opinion, sandboxing is very hard and not something we  
>>> can
>>> solve once, it requires continuous attention, so let's not even try
>>> it. Instead, the install addon operator should warn about security
>>> problems, and loading a .blend file with scripts should become  
>>> easi

Re: [Bf-committers] Python sandbox

[§ĥřïñïďĥï Ŗäö]

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 )

Well . i might be wrong here completely . but i dont think maya / houdini or
anyother softwares that use python has some sense of security (what might be
a security issue , actually may be a boon for many users ) . . Trust me .
the more we try to restrict a system the more unusable it becomes for
serious work. Its just that we have to trust the code that we use .This can
be accomplished through warnings and the ability to disable autoloading .
But again there should be an option to disable it too . Else blender will
stay a hobbyist software and will never be used in serious pipelines where
many tasks needs to be automated .  Restricting isnt a solution.

regards
shrinidhi


-- 
Ęvęņ ģóđ fąįļş ŧŏ ųŋđęŗşţąņđ å ĥųmąņ ųņţĭļ ĥĭş đęąţĥ

http://www.linkedin.com/in/shrinidhi666
http://www.shrinidhi666.wordpress.com
http://www.imdb.com/name/nm3025616
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Python sandbox

[Matt Ebb]

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@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Python sandbox

[Mike Belanger]

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  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@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
www.watchmike.ca
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Python sandbox

[Leif Andersen]

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 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  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@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
>
>
>
> --
> www.watchmike.ca
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Python sandbox

[Campbell Barton]

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
 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 
> 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  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@blender.org
>> > http://lists.blender.org/mailman/listinfo/bf-committers
>> >
>>
>>
>>
>> --
>> www.watchmike.ca
>> ___
>> Bf-committers mailing list
>> Bf-committers@blen

Re: [Bf-committers] Python sandbox

[joe]

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  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
>  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 
>> 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  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'

Re: [Bf-committers] Python sandbox

[Leif Andersen]

Joe;

Yes, but on the off chance that the user does add  a malicious .blend file?
As was said earlier in this thread, there needs to be a way of recuperating
from it, if at all possible.  Putting a pop up only solves half of the
problem.  (Then again, I think providing a good way to recuperate will only
solve half of the remaining half of the problem).

~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 17:53, joe  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 
> 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
> >  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 <
> mikejamesbelan...@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  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 

Re: [Bf-committers] Python sandbox

[Mike Belanger]

> , 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  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 
>> 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
>>>  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 <
>> mikejamesbelan...@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  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 )
>

Re: [Bf-committers] Python sandbox

[Leif Andersen]

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 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  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 
> >> 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
> >>>  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 <
> >> mikejamesbelan...@gmail.com>wrote:
> 
> > To me its not a question of how secure your pipeline is, but how
> >> quickly
> > you
> >

Re: [Bf-committers] Python sandbox

[Wahooney]

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 
> Belangerwrote:
>
>
>>> , 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  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
 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
>   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 

Re: [Bf-committers] Python sandbox

[Chris Gunn]

That would be about as successful as an Australian Internet Filter

Probably the easiest way to sandbox the python scripts is to sandbox the
python executable within the OS itself. That is, set up a dummy user within
the OS with no login rights, etc and do a run as.

Then all that you have to do to stop evil scripts from doing evil things
within the OS is to limit the dummy user where appropriate within the OS.
Eg, file permissions

Obviously this type of feature would be too advanced and complicated for the
typical user. Though on mission critical production machines this might be
worth the effort. That is, it would need to be an opt in feature.

I could be completely wrong but I suspect this would be a lot "easier" than
what has been previously mentioned. The main challenge being getting one set
of code to play nice on all OSs.

In terms of evil python scripts doing evil things within blender - use
subversion.

Chris

On Tue, Mar 23, 2010 at 5:25 PM, Wahooney  wrote:

> 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 >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  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 >
>  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 swi

Re: [Bf-committers] Python sandbox

[Campbell Barton]

@Wahoony, detecting bad calls wouldn't work well, you could easily
construct commands and execute them without the parser knowing. Even
stupid stuff like making each character an item in a list, joining it,
and running would work.

@Chris, since python is embedded in blender this would mean sandboxing
the blender executable too.

On Tue, Mar 23, 2010 at 7:47 AM, Chris Gunn  wrote:
> That would be about as successful as an Australian Internet Filter
>
> Probably the easiest way to sandbox the python scripts is to sandbox the
> python executable within the OS itself. That is, set up a dummy user within
> the OS with no login rights, etc and do a run as.
>
> Then all that you have to do to stop evil scripts from doing evil things
> within the OS is to limit the dummy user where appropriate within the OS.
> Eg, file permissions
>
> Obviously this type of feature would be too advanced and complicated for the
> typical user. Though on mission critical production machines this might be
> worth the effort. That is, it would need to be an opt in feature.
>
> I could be completely wrong but I suspect this would be a lot "easier" than
> what has been previously mentioned. The main challenge being getting one set
> of code to play nice on all OSs.
>
> In terms of evil python scripts doing evil things within blender - use
> subversion.
>
> Chris
>
> On Tue, Mar 23, 2010 at 5:25 PM, Wahooney  wrote:
>
>> 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> >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  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> >
>>  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 

Re: [Bf-committers] Python sandbox

[Rick Yorgason]

I've been following this discussion for a while.  Incidentally, I just
read a little blurb from Herb Sutter's blog regarding security:

http://herbsutter.com/2010/03/22/links-i-enjoyed-reading-this-week-2/

The moral of the story is that the danger of attacks is directly
proportional to the popularity of your product, so every time you work
to make Blender more popular, you're also raising the danger of attacks.
  Clearly, something has to be done sooner or later, unless you don't
expect Blender to get more popular.

That isn't to say that something has to be done *today*, but something
definitely has to be done.

One particularly nasty attack I can think of is to write a Blender
virus: when you open a .blend file and run its scripts (either because
scripts are enabled by default, or you didn't realize one of the scripts
was a virus; remember, some of the scripts might actually be legit) it
infects your Blender install, and subsequently infects all your personal
.blend files, all without your knowledge.  Then of course, when you send
your .blend files to somebody that trusts you, they don't even question
the scripts, and the virus spreads.  And this virus can do anything,
like silently log your keystrokes, or delete all your files on the 1st
of April.

The point has been brought up that a lot of Blender is run by Python
scripts, but that's okay.  The scripts that ship with Blender don't need
to be run in a sandbox; only the scripts in a .blend file need to.
After all, if the scripts that Blender ships have been compromised, then
your machine has already been owned.

Once you have a sandbox set up for you .blend scripts, you need to
figure out ways to allow certain things that wouldn't normally be
allowed in a sandbox, such as file access.  These aren't impossible
problems, but you might have to be creative (e.g. you can only open
files via a file selection widget, and that widget can't be populated
programmatically).

That would involve deprecating your API (again) and is a lot of work,
but it has to be done eventually.  You don't have to do it today, but
it's worth thinking about it today.

Finally, somebody in this thread said that everybody nowadays keeps
adequate backups.  I'd really like to live in that fantasy world!

-Rick-

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Python sandbox

[Benjamin Tolputt]

Rick Yorgason wrote:
> The moral of the story is that the danger of attacks is directly
> proportional to the popularity of your product, so every time you work
> to make Blender more popular, you're also raising the danger of attacks.
>   Clearly, something has to be done sooner or later, unless you don't
> expect Blender to get more popular.
>   

Pretty much the point of the "pro-security" folks in the discussion from
what I can tell. No-one argues that Blender is a small target now and,
as such, is unlikely to to be interesting to a malware developer. Thing
is, as soon as Blender is as popular as, say, MudBox or Silo it will be
targeted. Both of these applications have magnitudes less exposure to
the world than Maya, 3DS, etc - yet have trojan hacks out there for
people to install on their machines. And unlike Blender & Microsoft
Word, they can't spread via files saved by a compromised installation.

> That isn't to say that something has to be done *today*, but something
> definitely has to be done.
>   

I would agree but I think nigh on all but Ton in the core dev group do
not. Due to the fact Python simply *cannot* be sand-boxed and operate as
expected, this is a task that is too hard to consider right now and, as
such, will need to wait until a malicious Blender macro virus manages to
hurt enough people to being the issue front & centre.

Honestly, due to the fact that Python CANNOT be sand-boxed in a
reasonable fashion without the cooperation of the Python development
team (i.e. is not something the Blender developers can actually control)
- this issue is not going to be dealt with until disaster strikes
because it cannot be. The choice is, currently, twisting the arms of the
Python folks to secure Python in a way they disagree with (they don't
like embedding Python, they prefer you extend Python with your apop) OR
leaving Python behind and choosing an alternative (at least for scripts
internal to a .blend file run automatically by Blender).

Neither option is going to make people happy until such time as their
are hurt by the vulnerability. Remember, Microsoft did next to nothing
to secure their products (Office, Windows, etc) until disaster hit them
repeatedly... and they are a company with a large amount of cash to
spend on development.

> Finally, somebody in this thread said that everybody nowadays keeps
> adequate backups.  I'd really like to live in that fantasy world

Yeah, same here. I'm a tech head who is quite conscious of the issues
requiring backups and I've been nailed too often to think that your
average artist will be unaffected by their machine getting owned.
Especially if the malware is insidious and it has been doing things on
you machine for a while before discovery.


-- 
Regards,

Benjamin Tolputt
Analyst Programmer

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers