[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
<leif.a.andersen at gmail.com> wrote:
> As sad as it is, it seams like your axiom Jonathan, has been true.
> Although, that is based only on empirical evidence, not an actual rigorous
> proof.  (i.e., I would die happy if I ever found a way to make a computer be
> secure, and work seamlessly).  Some examples of this are the previous emails
> in this thread, about people who have had trouble with a locked down python.
>
> I still think though (like the first email in this thread), that it would be
> better to keep python separate, but still make sure that it has been
> included on the system.  We could also have a script that checks to make
> sure it is still the latest version, in an attempt to keep it secure.  If we
> include python directly into blender, that would add a severe amount of
> overhead to ensure that blender keeps up with the latest build of python,
> and even worse, if we customize it with patches, we would have to constantly
> repatch it, work that would be better spend fixing bugs/other flaws unique
> to blender/adding new features.Than again, on the other hand, we may have to
> still do the same thing if we try to customize a separate python build.
>
> Than again, all of this is at a very hand wavy level.  And my arguments seem
> to me consist of me waving my arms, and claiming I can fly. :)
>
> Anyway, thank you for the support thus far everyone.
>
> ~Leif Andersen
>
> ----------
> So Much to Learn, Such Little Time
> http://leifandersen.net/2010/02/03/so-much-to-learn-such-little-time/
>
>
> On Thu, Mar 18, 2010 at 12:43, Mike Belanger <mikejamesbelanger at gmail.com>wrote:
>
>> To me its not a question of how secure your pipeline is, but how quickly
>> you
>> can 'bounce back' after a system failure, maliciously-motived or otherwise.
>> Yeah, you should have a firewall, passwords, admin rights etc.  But really,
>> the best insurance policy for studio assets is automated-backup.
>> If anything, this sandbox thing almost sounds like it could restrict
>> backups, or make them difficult/require consent every save.  Anything
>> discouraging/inhibiting backup is a far bigger threat, imho.
>>
>> A disclaimer in front of AddOns works for me.
>>
>>
>> On Wed, Mar 17, 2010 at 11:28 PM, Matt Ebb <matt at mke3.net> wrote:
>>
>> >
>> > On 18/03/2010, at 15:09 , §ĥřïñïďĥï Ŗäö wrote:
>> >
>> > > Hi,
>> > > This is my very first mail to this list . I am not a developer but I
>> > > thought
>> > > i will put my 2 cents here since I felt that this discussion is a
>> > > waste of
>> > > time for many reasons .
>> > > 1: +100 for Brecth and his opinion (He is perfectly right !!)
>> > > 2: sanboxing blender will make it unusable  in large pipelines where
>> > > we need
>> > > blender to be integrated with other softwares and also need to do a
>> > > lot of
>> > > automatic IO (this includes IO to databases and in  renderfarm too
>> > > which can
>> > > be used for other than just rendering out images )
>> >
>> > +1 to this too. Even in 2.4* we had lots of trouble at our studio with
>> > scriptlinks, pydrivers, etc being off by default. We had problems (and
>> > wasted hours of work) when an artist took work home, installed a
>> > default blender from online and worked with that - getting the file
>> > into a state that caused lots of problems when the scripts were
>> > working as intended. This may have happened more than once too, can't
>> > remember. Similar trouble when doing some complicated things and
>> > sending files out to other studios who weren't familiar with Blender
>> > and this particular issue that really doesn't affect them.
>> >
>> > Many people who use blender don't download and open files from
>> > strangers on the web, and I would not like to see practical usability
>> > hindered just to try and give people who do the impression of security.
>> >
>> > cheers,
>> >
>> > Matt
>> >  _______________________________________________
>> > Bf-committers mailing list
>> > Bf-committers at blender.org
>> > http://lists.blender.org/mailman/listinfo/bf-committers
>> >
>>
>>
>>
>> --
>> www.watchmike.ca
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell