[Bf-committers] Python sandbox

Campbell Barton ideasman42 at gmail.com
Tue Mar 23 07:58:17 CET 2010


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


More information about the Bf-committers mailing list