一级做人爱c视正版免费

[David Wilson]

Hi Patrick,

So finally I'm getting around to replying. :)

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:

    * Ensuring parent process heap / environment / file descriptors do not
leak.

    * 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.

    * Ensuring parent<->child communication is handled securely.

    * 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.

    * 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:


    class ChildResourcePolicy(ResourcePolicy):
        def check_tcp4_access(self, host, port):
            return False

        def check_udp4_access(self, host, port):
            return False

        def check_path_write(self, path):
            return False

        ALLOW_PATHS = set(['/etc/services'])
        def check_path_read(self, path):
            return path in self.ALLOW_PATHS

etc.


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.

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.


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.


David



On 23 February 2015 at 16:51, Patrick Schleizer <adrelanos at riseup.net>
wrote:

> Hi David!
>
> Would it be useful to combine pypy with seccomp.py?
>
> With it be useful to combine pypy sandbox with seccomp.py?
>
> Do you know any usage examples of seccomp.py by any projects?
>
> Why is there no existing python library for this feature? One could
> assume, that this is quite popular and installable from mainstream
> distributions such as Debian?
>
> Anything else you would like to add?
>
> By replying to this mail, your answer will be posted on the whonix-devel
> public mailing list, so all of our python coders can benefit from your
> answer.
>
> Cheers,
> Patrick
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.whonix.org/pipermail/whonix-devel/attachments/20150425/bd98afd5/attachment.html>