为此提供绝对解决方案是不可能的,因为“坏”的定义很难确定。
打开和写入文件是坏还是好?如果该文件是/ dev / ram怎么办?
您可以描述行为的签名,或者您可以尝试阻止任何可能不好的事情,但您永远不会赢。 Javascript就是一个非常好的例子,人们在他们的计算机上一直运行任意javascript代码 - 它应该是沙箱,但是会出现各种各样的安全问题和边缘条件。
我不是说不试试,你会学到的 很多 从过程中。
许多公司花费了数百万美元(英特尔只花了数十亿美元用于McAffee)试图了解如何检测“坏代码” - 每天运行McAffe反病毒的机器都会感染病毒。 Python代码没有C语言那么危险。您可以运行系统调用,绑定到C库等。
我认为像这样的解决方案会非常困难,这让我想起了我参加的关于虚拟环境中编程优势的讲座。 如果你这样做的话,它实际上很酷。它不会解决一段时间True:传递但rm -rf /无关紧要。
你可以检查一下 pysandbox 就是这样,虽然如果你能负担得起,VM路线可能更安全。
除非我弄错了(我很可能),这也是Google为App Engine改变Python的原因所在。您在他们的服务器上运行Python代码,但他们已经删除了写入文件的能力。所有数据都保存在“nosql”数据库中。
这不是你问题的直接答案,而是在某些情况下如何处理这个问题的一个例子。
如果您不是特定于CPython实现,您应该考虑查看 PyPy [维基] 出于这些目的,这种Python方言允许透明的代码沙盒。
否则,你可以提供假货 __builtin__ 和 __builtins__ 在相应的globals / locals参数中 exec 要么 eval 。
__builtin__
__builtins__
exec
eval
此外,您可以提供类似字典的对象而不是真正的字典,并跟踪不受信任的代码对其命名空间的影响。
而且,您实际上可以跟踪该代码(发布 sys.settrace() 在任何其他代码执行之前在受限制的环境中)所以如果某些事情会变坏,你可以中断执行。
sys.settrace()
如果没有一个解决方案可以接受,请使用OS级沙盒 chroot , unionfs 和标准 multiprocess python模块在单独的安全进程中生成代码工作者。
chroot
unionfs
multiprocess
你可以尝试一些通用的沙盒,如 Sydbox 要么 Gentoo的沙箱 。它们不是特定于Python的。
两者都可以配置为限制对某些目录的读/写。 Sydbox甚至可以使用沙盒插槽。
我会认真考虑虚拟化环境来运行这些东西,这样你实现的任何机制中的漏洞都可以通过配置虚拟机再次防火墙。
用户数量以及您希望测试/运行的代码类型将对btw的选择产生相当大的影响。如果不期望它们链接到文件或数据库,或者运行计算密集型任务,并且压力非常低,那么只需完全阻止文件访问并在进程被杀死之前对进程施加时间限制就可以了。提交标记为太昂贵或恶意。
如果您要测试的代码可能是任意Django扩展或页面,那么您可能需要做很多工作。