<div dir="ltr"><div><div>Hi Patrick,<br><br></div>So finally I'm getting around to replying. :)<br><br></div><div>There is room for a Python-specific library for handling restricted execution using OS facilities, and one I briefly toyed with creating, however since I had no personal use for it I did not explore any further. The reason for desiring a reusable library to handle this is that there are a number of subtleties to implementing it correctly and securely:<br><br></div><div>    * Ensuring parent process heap / environment / file descriptors do not leak.<br></div><div><br>    * Ensuring child process can allocate RAM/CPU up to some configurable limit, and fails gracefully when those limits are reached. CPU limit can be done with setrlimit(2), but RAM limit requires a little more care.<br></div><div><br>    * Ensuring parent<->child communication is handled securely.<br><br></div><div>    * Ensuring child process has access to a whitelisted set of modules, and ensuring the whitelisted set does not cause a large startup time. This would probably entail forking a "prototypical child" that has all necessary modules loaded, and forking+seccomping this child each time a new context should be created.<br><br></div><div>    * Potential for some customizable policy for the child. For example, virtualizing filesystem / socket access (which can be done with seccomp traps). For example letting the user implement a class like:<br><br></div><div><br>    class ChildResourcePolicy(ResourcePolicy):<br>        def check_tcp4_access(self, host, port):<br>            return False<br><br>        def check_udp4_access(self, host, port):<br>            return False<br><br>        def check_path_write(self, path):<br>            return False<br><br>        ALLOW_PATHS = set(['/etc/services'])<br>        def check_path_read(self, path):<br>            return path in self.ALLOW_PATHS<br><br></div><div>etc.<br></div><div><br><br>I had also considered trying to abstract away OS X sandbox(7) and Linux PR_SET_SECCOMP behind a uniform interface, however that would potentially weaken the featureset and promises made by the resulting library, since sandbox(7) is nowhere nearly as capable or isolated as seccomp is.<br><br></div><div>Regarding use with PyPy, there is no reason the same library could not work there. PyPy has its own sandboxing facilities, but at least to me their design is significantly more complicated (and potentially less reliable) than the equivalent OS facility.<br></div><div><br></div><div><br>As for why no such library exists already, perhaps it is because this is a relatively niche use case, and for those places where it might be in use (e.g. platforms like Google App Engine), the implementation might be considered highly proprietary/confidential, and unlikely a good target for open sourcing.</div><div><br><br></div><div>David<br></div><div><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 23 February 2015 at 16:51, Patrick Schleizer <span dir="ltr"><<a href="mailto:adrelanos@riseup.net" target="_blank">adrelanos@riseup.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi David!<br>
<br>
Would it be useful to combine pypy with seccomp.py?<br>
<br>
With it be useful to combine pypy sandbox with seccomp.py?<br>
<br>
Do you know any usage examples of seccomp.py by any projects?<br>
<br>
Why is there no existing python library for this feature? One could<br>
assume, that this is quite popular and installable from mainstream<br>
distributions such as Debian?<br>
<br>
Anything else you would like to add?<br>
<br>
By replying to this mail, your answer will be posted on the whonix-devel<br>
public mailing list, so all of our python coders can benefit from your<br>
answer.<br>
<br>
Cheers,<br>
Patrick<br>
</blockquote></div><br></div>