On Fri, Jun 7, 2013 at 7:21 PM, Ton Roosendaal <t...@blender.org> wrote: > Hi Campbell, > > I don't know enough about Python internals, so I depend on someone to help > designing a sane way to handle security risks here. There must be ways we can > help users?
So far I can only see the way to help users is limited to them running executable code bundled with a blend, or not. (as has been discussed) > Look for example at the standard UI scripts. Apart from 1 case, there's no > "import os" anywhere. Same goes for essential scripts riggers or animators > use. > > So, why not add a provision in Blender code to check on such cases. Just > don't allow import of any module = safe script? In all other cases: needs to > be explicitly permitted to run. Limiting module access is just really hard to do... this isn't about being a smart-arse, its just that the way CPython works makes this near impossible unless you remove the functionality altogether. Even if importing of modules is disabled you can use namespace tricks to access modules. eg: os = next(iter(i for i in (1).__class__.__mro__[-1].__subclasses__() if i.__name__ == '_ZipDecrypter'))._UpdateKeys.__globals__["so"[::-1]] Of course you can start to disable CPythons own introspection then this could be disabled but Blender currently takes advantage of this in some places so as Brecht says - this ends up becoming a large project we need to maintain, its not just some 1-2 week project to come up with a safe version of CPython. > Something like this would make a "trusted source" option on file loading more > useful. Right now, unticking "trusted source" is almost equivalent to > "disable useful features". With drivers yes, further though I don't think many blend files need to execute code. > -Ton- _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
