我以前总是将 bind9 安装保存在 chroot jail 中。现在我升级了我的 vServer，必须重新安装 bind9。由于我的托管服务提供商使用的虚拟化解决方案，我无法自己创建设备（/jail/dev/random和/jail/dev/null），而我的托管服务提供商为此收取 20 欧元的费用。
到引用阿德里安·邦克，
实施安全解决方案的人员能力不足是一个真正的问题。Chroot 不是也从来不是一个安全工具。人们基于 chroot 的属性构建了一些东西，但进行了扩展（BSD jails、Linux vserver），但它们完全不同。
据我理解，在 chroot 中以 root 身份运行软件毫无意义，因为 root 用户总能逃脱牢狱之灾。但如果我以非特权用户身份运行软件，它仍应提供额外的安全性，对吗？
总而言之，将 bind9 放入 chroot jail 中是否值得花费 20 欧元？
答案1
好吧，lkml 讨论的是 root 用户逃离 chroot jail，而 bind 永远不会使用 root 权限在 chroot jail 中运行。因此，如果攻击者破坏了 bind 进程，他/她仍然必须找到一个漏洞来逃离 chroot jail。
答案2
我意识到这有点晚了，但就 chroot 不提供任何“真正的”安全性而言-
这完全是错误的！
整个主意安全性在于它是分层提供的。一个主要的提示，以及许多发行版背后的驱动力，是只提供基本必需品（就包而言）。这是因为它减少了攻击面。
本质上，chroot 是一个虚拟化的文件系统。不多也不少。然而，常见的误解是，如果有人可以“打破束缚”，那么他们也可以摆脱 chroot...
但是如何呢？首先，关于为什么“chroot 毫无价值”的整个讨论是因为以 root 身份运行的守护进程可能会受到损害，从而允许 root 权限提升。但大多数发行版都以用户名或 bind 运行 Bind9。
因此，如果攻击者曾是为了攻陷 Bind，攻击者必须彻底搜索虚拟文件系统 (chroot jail)，寻找可利用的应用程序、库、setuid 可执行文件等，使用缓冲区溢出或使用文件描述符等，并将有效载荷传递到基础系统中执行
如果使用，Chroot Jails 可以很好地工作适当地
chroot 背后的整个想法是提供运行 Bind 所需的绝对基本要素（在本例中）。它是不是在一个 chroot 中运行多个应用程序是一个好主意，将 chrooted 用户放在 jail 中也不是一个好主意，旁边你的绑定的 chroot 实例。这只会增加潜在的攻击面。
每个应用程序（具体来说，接受输入的复杂前向服务，直接与网络通信）都应该驻留在自己的 chroot jail 中。你可以将所有用户放在一个 chroot jail 中，但要尽量减少可能的攻击面在您的用户之间（并提供更多潜在的隐私），最好的选择是让每个用户都处于自己的 chroot 监狱中。
最后，必须确保基础系统的安全全部内容. 这样，如果你在 chroot jail 中留下了一些可利用的东西，他们就必须先破坏基础系统，然后才能造成任何真正的损害（除了 Bind 和它的 Chroot Jail）
注意我说的是“你”；唯一能挑出这一过程（因此导致 chroot jail 不安全）的人是你自己. 有时错误的更新或零日漏洞会出现漏洞，但大多数时候这是惯常的人为错误。
实施安全解决方案的不称职的人员是一个真正的问题。
我对此的回应是，虽然这正是问题所在（人们误用了 chroot），但它曾是适合用作安全解决方案，并且有多年来已被用于许多解决方案（并取得了巨大的成功）。生活中并非所有事物最终都能用于其预期目的，而这显然是其中之一。
一个完美的例子就是 Web 托管控制面板。他们经常使用 chroot 来分离用户。此外，它在 Dovecot、Sendmail、Apache/Mod_Security、OpenSSH 等标题中都有可用的实现，并且已经被许多库用来提供安全性，其中一个例子就是 pam_chroot。
简单的搜索就能发现这种功能的可信度，而将系统安全性的判断建立在“误解的误解”之上简直是无稽之谈
答案3
chroot 不会限制攻击者对文件子集的访问，从而使得一开始就更难找到特权提升漏洞吗？如果是这样，那么它可以用作安全工具。相关阅读：http://www.openbsd.org/faq/faq10.html#httpdchroot