On 17 Sep, 07:26, "Aaron \"Castironpi\" Brady" <[EMAIL PROTECTED]> wrote: > Sometimes questions come up on here about unpickling safely and > executing foreign code. I was thinking a minimum install that didn't > even have access to modules like 'os' could be safe. (Potentially.) > I have time to entertain this a little, though all the devs are busy. > I can bring it up again in a few months if it's a better time.
One alternative might be to provide "safe" versions of the underlying functions in modules like "os". Previously, I did wonder why people didn't link Python against a bunch of alternative libraries which would provide implementations of things like "open", "chdir" and so on, but then I was made aware of fakeroot and fakechroot which do more or less this for any program (in conjunction with chroot) in order to restrict the behaviour of those programs, without any need to statically link the programs first. [...] > A lot of modules would have to go. <Long list> IPC modules: > subprocess, socket, signal, popen2, asyncore, asynchat. ctypes, mmap, > platform.popen, glob, shutil, dircache, and many more</Long>. Potentially, these could remain, but you'd want to provide "fake" versions of the underlying functions, potentially implementing your own preferred flavour of access control. So, with a call to the "socket" function, the wrapped version might first consult some kind of behaviour policy set by the user in order to get permission to open a connection to a remote host. There's a discussion of rexec and related solutions on the Wiki: http://wiki.python.org/moin/How_can_I_run_an_untrusted_Python_script_safely_(i.e._Sandbox) Paul -- http://mail.python.org/mailman/listinfo/python-list
