On Tue, Nov 12, 2013 at 01:16:55PM -0800, Victor Stinner wrote:
> pysandbox cannot be used in practice
> ====================================
>
> To protect the untrusted namespace, pysandbox installs a lot of
> different protections. Because of all these protections, it becomes
> hard to write Python code. Basic features like "del dict[key]" are
> denied. Passing an object to a sandbox is not possible to sandbox,
> pysandbox is unable to proxify arbitary objects.
>
> For something more complex than evaluating "1+(2*3)", pysandbox cannot
> be used in practice, because of all these protections. Individual
> protections cannot be disabled, all protections are required to get a
> secure sandbox.
This sounds a lot like the work I initially did with PyParallel to
try and intercept/prevent parallel threads mutating main-thread
objects.
I ended up arriving at a much better solution by just relying on
memory protection; main thread pages are set read-only prior to
parallel threads being able to run. If a parallel thread attempts
to mutate a main thread object; a SEH is raised (SIGSEV on POSIX),
which I catch in the ceval loop and convert into an exception.
See slide 138 of this:
https://speakerdeck.com/trent/pyparallel-how-we-removed-the-gil-and-exploited-all-cores-1
I'm wondering if this sort of an approach (which worked surprisingly
well) could be leveraged to also provide a sandbox environment? The
goals are the same: robust protection against mutation of memory
allocated outside of the sandbox.
(I'm purely talking about memory mutation; haven't thought about how
that could be extended to prevent file system interaction as well.)
Trent.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
