Just as a random side note, this reminds me a bit of https://gvisor.dev/ On Tue, Aug 13, 2019, 4:41 AM Armin Rigo <armin.rigo@gmail.com> wrote:

Hi all,

I've got an early but probably usable PyPy and PyPy3 with sandboxing. Like the old sandboxing, these new versions are made out of a special version of PyPy (or PyPy3, which is new), running in a mode where no direct I/O should be possible; and a separate controller process.

The communication between these two processes has been rewritten. Now, it actually looks similar to the communication between a process and a OS kernel. For example, when a regular process wants to write data to a file, it calls the OS function "write(int fd, char *buf, size_t count)" (actually it calls the standard C library, which is itself a relatively thin wrapper around the OS, but we'll ignore that). Then the OS proceeds to read directly the part of the memory owned by the process, from addresses "buf" to "buf + count".

In the sandboxed version of PyPy, this is replaced by the sandboxed process saying to the controller process "I'm trying to call write() with these three arguments: two numbers and one pointer". Assuming that the controller supports "write()", it contains logic that will then ask the sandboxed process for the content of some of its memory, from "buf" to "buf + count".

In other system calls like "read(fd, buf, count)", the controller would write (instead of reading) data into the sandboxed process' raw memory, between "buf" and "buf + count".

This approach means that a single sandboxed PyPy (or PyPy3) is needed, and it supports out of the box all "system calls". It's up to the controller process to either support them or not, and when it does, to do things like (if necessary) reading and writing raw memory from/to the sandboxed subprocess. It puts more responsibility into the hands of the controller process, but is also far more flexible. It is the same security approach as for the OS, basically: the sandboxed process can do whatever it wants but all its I/O are tightly controlled.

Sources:

* The sandboxed PyPy including the necessary RPython changes is in PyPy's standard repo, branch "sandbox-2". Translate with ``rpython/bin/rpython -O2 --sandbox``.

* The PyPy3 version is in the branch "py3.6-sandbox-2". Same command to translate.

* The controller process, or at least one possible version of it, has been split into its own repo: http://bitbucket.org/pypy/sandboxlib . This is CPython-or-PyPy-2-or-3 source code. You need to run ``setup.py build_ext -f -i``. To run the tests (with pytest), make a symlink from ``test/pypy-c-sandbox`` to the sandboxed version built above. Try also ``interact.py``.

Right now there is no way to limit the amount of RAM of CPU time consumed by the sandboxed process, but I think it should be done with standard platform tools (e.g. ``ulimit``).

Please try it out and give me any feedback !

A bientôt,

Armin. _______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev

Just as a random side note, this reminds me a bit of https://gvisor.dev/ On Tue, Aug 13, 2019, 4:41 AM Armin Rigo <armin.rigo@gmail.com> wrote:

Hi all,

I've got an early but probably usable PyPy and PyPy3 with sandboxing. Like the old sandboxing, these new versions are made out of a special version of PyPy (or PyPy3, which is new), running in a mode where no direct I/O should be possible; and a separate controller process.

The communication between these two processes has been rewritten. Now, it actually looks similar to the communication between a process and a OS kernel. For example, when a regular process wants to write data to a file, it calls the OS function "write(int fd, char *buf, size_t count)" (actually it calls the standard C library, which is itself a relatively thin wrapper around the OS, but we'll ignore that). Then the OS proceeds to read directly the part of the memory owned by the process, from addresses "buf" to "buf + count".

In the sandboxed version of PyPy, this is replaced by the sandboxed process saying to the controller process "I'm trying to call write() with these three arguments: two numbers and one pointer". Assuming that the controller supports "write()", it contains logic that will then ask the sandboxed process for the content of some of its memory, from "buf" to "buf + count".

In other system calls like "read(fd, buf, count)", the controller would write (instead of reading) data into the sandboxed process' raw memory, between "buf" and "buf + count".

This approach means that a single sandboxed PyPy (or PyPy3) is needed, and it supports out of the box all "system calls". It's up to the controller process to either support them or not, and when it does, to do things like (if necessary) reading and writing raw memory from/to the sandboxed subprocess. It puts more responsibility into the hands of the controller process, but is also far more flexible. It is the same security approach as for the OS, basically: the sandboxed process can do whatever it wants but all its I/O are tightly controlled.

Sources:

* The sandboxed PyPy including the necessary RPython changes is in PyPy's standard repo, branch "sandbox-2". Translate with ``rpython/bin/rpython -O2 --sandbox``.

* The PyPy3 version is in the branch "py3.6-sandbox-2". Same command to translate.

* The controller process, or at least one possible version of it, has been split into its own repo: http://bitbucket.org/pypy/sandboxlib . This is CPython-or-PyPy-2-or-3 source code. You need to run ``setup.py build_ext -f -i``. To run the tests (with pytest), make a symlink from ``test/pypy-c-sandbox`` to the sandboxed version built above. Try also ``interact.py``.

Right now there is no way to limit the amount of RAM of CPU time consumed by the sandboxed process, but I think it should be done with standard platform tools (e.g. ``ulimit``).

Please try it out and give me any feedback !

A bientôt,

Armin. _______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev