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 <[email protected]> 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 <[email protected]> wrote: > >> On Wed, Mar 17, 2010 at 9:50 AM, Ton Roosendaal <[email protected]> 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<http://people.cs.ubc.ca/%7Edrifty/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 >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers >> > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > -- - Campbell _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
