[Python-Dev] Add a frozendict builtin type

[Guido van Rossum]

On Thu, Mar 1, 2012 at 2:01 AM, Victor Stinner
<victor.stinner at haypocalc.com> wrote:
>>> The main idea of pysandbox is to reuse most of CPython but hide
>>> "dangerous" functions and run untrusted code in a separated namespace.
>>> The problem is to create the sandbox and ensure that it is not
>>> possible to escape from this sandbox. pysandbox is still a
>>> proof-of-concept, even if it works pretty well for short dummy
>>> scripts. But pysandbox is not ready for real world programs.
>>
>> I hope you have studied (recent) history. Sandboxes in Python
>> traditionally have not been secure. Read the archives for details.
>
> The design of pysandbox makes it difficult to implement. It is mostly
> based on blacklist, so any omission would lead to a vulnerability. I
> read the recent history of sandboxes and see other security modules
> for Python, and I don't understand your reference to  "Sandboxes in
> Python traditionally have not been secure." There is no known
> vulnerability in pysandbox, did I miss something? (there is only a
> limitation on the dict API because of the lack of frozendict.)
>
> Are you talking about rexec/Bastion? (which cannot be qualified as "recent" :-))
>
> pysandbox limitations are documented in its README file:
>
> << pysandbox is a sandbox for the Python namespace, not a sandbox between Python
> and the operating system. It doesn't protect your system against Python
> security vulnerabilities: vulnerabilities in modules/functions available in
> your sandbox (depend on your sandbox configuration). By default, only few
> functions are exposed to the sandbox namespace which limits the attack surface.
>
> pysandbox is unable to limit the memory of the sandbox process: you have to use
> your own protection. >>
>
> Hum, I am also not sure that pysandbox "works" with threads :-) I mean
> that enabling pysandbox impacts all running threads, not only one
> thread, which can cause issues. It should also be mentioned.
>
> PyPy sandbox has a different design: it uses a process with no
> priviledge, all syscalls are redirected to another process which apply
> security checks to each syscall.
> http://doc.pypy.org/en/latest/sandbox.html
>
> See also the seccomp-nurse project, a generic sandbox using Linux SECCOMP:
> http://chdir.org/~nico/seccomp-nurse/
>
> See also pysandbox README for a list of other Python security modules.

Hm. I can't tell what the purpose of a sandbox is from what you quote
from your own README here (and my cellphone tethering is slow enough
that clicking on the links doesn't work right now).

The sandboxes I'm familiar with (e.g. Google App Engine) are intended
to allow untrusted third parties to execute (more or less) arbitrary
code while strictly controlling which resources they can access. In
App Engine's case, an attacker who broke out of the sandbox would have
access to the inside of Google's datacenter, which would obviously be
bad -- that's why Google has developed its own sandboxing
technologies.

I do know that I don't feel comfortable having a sandbox in the Python
standard library or even recommending a 3rd party sandboxing solution
-- if someone uses the sandbox to protect a critical resource, and a
hacker breaks out of the sandbox, the author of the sandbox may be
held responsible for more than they bargained for when they made it
open source. (Doesn't an open source license limit your
responsibility? Who knows. AFAIK this question has not gotten to court
yet. I wouldn't want to have to go to court over it.)

I wasn't just referring of rexec/Bastion (though that definitely
shaped my thinking about this issue; much more recently someone (Tal,
I think was his name?) tried to come up with a sandbox and every time
he believed he had a perfect solution, somebody found a loophole.
(Hm..., you may have been involved that time yourself. :-)

-- 
--Guido van Rossum (python.org/~guido)