解决方法
让我从一个小故事开始：回到当我在Linux发行版供应商的安全联系人时,PHP安全团队要求Linux供应商停止调用解释器崩溃的安全漏洞,即使PHP解释器在Web服务器内运行(比如说,Apache上的mod_PHP). (当时,每周大概有一次翻译崩溃.)
他们进行了一些谈话,实际上说服我们,提供运行的PHP代码的人是完全信任的,并且任何尝试控制脚本可以从翻译器执行的操作被误导 – 如果有人想出如何使解释器崩溃围绕它试图施加的限制(如entire silly safe mode pile of crap),这不是一个安全漏洞,因为脚本的安全执行不是PHP解释器的目标 – 它永远不会是永远不会的.
我对讨论的最终结果感到非常满意 – 它清楚地定义了PHP的安全目标：您应该只允许执行您100％完全信任的PHP代码.如果你不信任,你不会运行它.这很简单
无论操作系统资源可用于解释器,都可以使用和公平的游戏,无论脚本是使用解释器中的错误还是发生意想不到的事情.
所以,请不要让随机代码在您的网络服务器的上下文中执行,除非这是您真正想要的.
请使用principle of least privilege指导每个程序可用的资源.
考虑使用AppArmor,SELinux,TOMOYO或SMACK等mandatory access control工具进一步限制您的程序可以做什么和不能做什么.自2001年以来,我已经在AppArmor项目上工作,相当有信心,通过一天的努力,大多数系统管理员可以通过AppArmor以有意义的方式增强他们的站点安全性.请评估几个选项,因为不同的工具围绕不同的安全模型设计 – 一个或另一个可能更适合.
但无论你做什么,请不要运行您的服务器,不必要地打开它,以通过额外的向量攻击.
