minimum install & pickling

[Aaron "Castironpi" Brady]

On Sep 17, 4:43 am, Paul Boddie <p... at boddie.org.uk> wrote:
> On 17 Sep, 07:26, "Aaron \"Castironpi\" Brady" <castiro... at gmail.com>
> 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_...)
>
> Paul

These solutions have at least the same bugs that the bare bones
solution in the corresponding framework has.  Malicious code has fewer
options, but constructive code does too.  If you're running foreign
code, what do you want it to do?  What does it want to do?  The more
options it needs, the more code you have to trust.

The only way a Python script can return a value is with sys.exit, and
only an integer at that.  It is going to have output; maybe there's a
way to place a maximum limit on its consumption.  It's going to have
input, so that the output is relative to something.  You just make
copies to prevent it from destroying data.  Maybe command-line
parameters are enough.  IIRC if I recall correctly, Win32 has a way to
examine how much time a process has owned so far, and a way to
terminate it, which could be in Python's future.

PyPy sandbox says:  "The C code generated by PyPy is not
segfaultable."  I find that to be a bold claim (whether it's true or
not).

I'm imagining in the general case, you want the foreign code to make
changes to objects in your particular context, such as exec x in
vars.  In that case, x can still be productive without any libraries,
just less productive.