KCD*_*KCD 1 security web-server chroot best-practices apache-2.2
我并不是要质疑在大多数情况下将 apache 放入 chroot-jail 的完善的安全预防措施，但在我的情况下，我有疑问。
我们有一个托管单个应用程序的虚拟服务器 - 一个网络服务。本指南说我应该禁用对我来说不太安全的SELinux？所有这些都是为了在我们的应用程序遭到破坏后保护 Centos 安装的运行。
显然这有点主观，但在资源有限的小规模部署中，我们应该关注更好的方法吗？
Chroot 提供了一点安全性来为攻击者提供加速。如果您在 apache/CGI 中存在漏洞，攻击者必须逃离 chroot jail。自动攻击不太可能尝试这样做，但是如果存在已知的内核漏洞，并且可以在 chroot 环境中获得该漏洞的要求，那么您将受到打击。
SELinux 提供了更大的安全性，但实现的痛苦也不容小觑。对于简单的情况，可能有预先准备好的 SELinux 策略，但如果您正在做奇怪/自定义的事情，则需要自己扩展它们。如果您加载了 selinux 开发 RPM，这并不是非常困难。从非强制模式开始，完全锻炼你的系统，然后运行：
audit2allow -a -l -R -m foo -o foo.te
这将帮助您开发自定义策略。
与 SELinux 类似的步骤是 GRSecurity。它不太标准，但可能比 SELinux 更安全一点，并且可能更容易使用，尽管互联网上能够帮助你的人较少。
另一种方法是在 VM 中运行 Web 服务器。这为您提供了更多的安全性，但众所周知，攻击能够逃脱 VM 环境。但是，这些很可能是非常坚定的攻击者，而不是您的普通脚本小子。