Steven Bethard wrote: > Fuzzyman wrote: > > Cameron Laird wrote: > > [snip..] > > > >>This is a serious issue. > >> > >>It's also one that brings Tcl, mentioned several > >>times in this thread, back into focus. Tcl presents > >>the notion of "safe interpreter", that is, a sub- > >>ordinate virtual machine which can interpret only > >>specific commands. It's a thrillingly powerful and > >>correct solution to the main problem Jeff and others > >>have described. > > > > A better (and of course *vastly* more powerful but unfortunately only > > a dream ;-) is a similarly limited python virutal machine..... > > Yeah, I think there are a lot of people out there who would like > something like this, but it's not quite clear how to go about it. If > you search Google Groups, there are a lot of examples of how you can use > Python's object introspection to retrieve "unsafe" functions. > > I wish there was a way to, say, exec something with no builtins and with > import disabled, so you would have to specify all the available > bindings, e.g.: > > exec user_code in dict(ClassA=ClassA, ClassB=ClassB) > > but I suspect that even this wouldn't really solve the problem, because > you can do things like: > > py> class ClassA(object): > ... pass > ... > py> object, = ClassA.__bases__ > py> object > <type 'object'> > py> int = object.__subclasses__()[2] > py> int > <type 'int'> > > so you can retrieve a lot of the builtins. I don't know how to retrieve > __import__ this way, but as soon as you figure that out, you can then > do pretty much anything you want to. > > Steve
Wouldn't it be better to attach to all code objets some kind of access right marker and to create an opcode that calls a function while reducing the access rights ? After all, security would be easier to achieve if you prevented the execution of all the dangerous code rather than trying to hide all the entry points to it. -- http://mail.python.org/mailman/listinfo/python-list
