我认为你混淆了两件事。您的 Python 程序不是所谓的可执行文件libsandbox
。可执行文件是 Python 解释器。
因此,您不能使用libsandbox
.
但是,您可以对 Python 解释器进行沙箱处理。执行此操作的方式与对任何其他可执行文件进行沙箱处理相同。任何一个:
- 创建 Python 解释器的静态构建(包含您需要编译的任何 C 扩展模块),并在沙箱中运行它。这并不容易,但它是可行的,并且 Python 源代码树和其他地方的信息可能会有所帮助。
- 使用更宽松的沙箱,允许标准解释器做它需要的一切(可能包括动态加载扩展模块,取决于你是否需要),但仅此而已。
无论哪种方式,您都需要一些试验和错误来弄清楚您可以禁止什么和不能禁止什么,以及如何将不同的 Python 代码位映射到系统调用,等等。并且有些事情是您无法阻止脚本执行的,因为您不希望 Python 代码执行的相同系统调用对于解释器本身来说是必需的。
实际上,Java 也是如此。JVM 是可执行文件,而不是您的程序。而且你真的不能静态链接JVM,所以你只有第二种选择。
当然,除非您使用gcj
将 Java 代码编译为本机代码而不是 JVM 代码。在这种情况下,您实际上使用的是与gcc
and相同的后端g++
,并且您只是--static
用来确保libgcj
其他所有内容都静态链接。您可能仍然会遇到问题,因为libgcj
在幕后做的事情比libc
……更多,但概念与 C 代码相同。
(JVM 本身有自己的访问模型,您可能可以在类加载器中使用反射构建一些东西,以在 Java API 级别而不是 linux 系统调用 API 上沙箱 Java 程序。我不知道这样的东西是否已经存在.)
每当我尝试在没有“--static”的情况下编译程序(我想在沙箱中运行)时,沙箱都不起作用。所以,再次 --static 非常关键,这超出了我的知识范围。
最有可能的是,您的实际代码不会打开任何文件,因此您使用的是禁止打开文件的默认沙箱设置。但是如果你动态链接你的程序,它必须打开.so
文件来链接它们——这是行不通的,因为你的沙箱被配置为禁止它。
如果你静态链接同一个程序,问题就消失了,因为它不再需要打开任何.so
s 来运行。简而言之,这就是沙盒静态链接的重点。你甚至在对你的问题的评论中解释了这一点,所以我无法想象你是怎么理解它的,除非你甚至不明白你为什么要禁止SYS_open
以及这样做意味着什么。
(a) 对于 java 和 python,如果我编译 w/o“--static”,沙箱会工作吗
是的,沙盒可以正常工作。这意味着,如果您使用默认配置,它将禁止您打开文件。这意味着您的 Java 或 Python 程序将失败,因为 VM/解释器必须打开(除其他外)您的程序才能运行它。
即使静态链接解释器或 JVM 也无济于事。您必须将程序的实际字节码静态链接到可执行文件中。并非不可能,但可能远远超出您此时想要考虑的任何事情。
正确的做法是弄清楚您要禁止哪些系统调用,以及为什么要禁止,并适当地配置沙箱。默认配置对您不起作用。
(b)同一个开发者openjudge.net/~liuyu/Project/LibSandbox有一个叫pysandbox的沙箱
pysandbox
只是配置和启动沙箱的一种更简单的方法。您不会在沙盒代码中使用它。(另 pysandbox
一位开发人员在 Python 级别对您的代码进行沙箱处理。这可能对您有用,但它与系统调用沙箱不同。)
在这一点上,我不确定你甚至不知道你想要做什么。为什么要首先对代码进行沙箱化?你知道你的代码需要什么样的访问权限才能完成它需要做的事情吗?如果您知道自己要做什么,那么您确定系统调用级别的沙箱是执行它的正确级别,而不是像RestrictedPython
? 在不知道您的实际用例的情况下,我什至无法猜测这些问题的答案。但是,如果您对所有这些问题都没有立即的答案,那么您将无法完成任何有用的事情。