我总是习惯把我的bind9安装在chroot监狱里。 现在我升级了我的vServer，并且必须再次安装bind9。 由于托pipe服务提供商使用的虚拟化解决scheme，我无法自己创build设备（ /jail/dev/random和/jail/dev/null ），而我的托pipe服务提供商收取20欧元的费用。
引用 Adrian Bunk，
实施安全解决scheme的无能的人是一个真正的问题。 Chroot不是，也从来不是一个安全工具。 人们已经根据chroot的属性构build了一些东西，但扩展了（BSD jail，Linux vserver），但是它们是完全不同的。
就我所了解的这个讨论而言，在chroot中以root身份运行软件是毫无价值的，因为root用户总是可以逃离监狱。 但是，如果我作为非特权用户运行它，它应该仍然提供额外的安全性，正确的？
总而言之，将bind9放入chroot监狱是否值得20欧元？
那么，lkml的讨论是关于root用户转义chroot jail和bind从来没有运行在chroot jail使用root权限。 所以，如果攻击者损害绑定过程，攻击者仍然必须find一个漏洞来逃脱chroot监狱。
我意识到这有点晚了，但只要没有提供任何“真正的”安全性的chroot，
这是错的！
整个安全的想法就是它是分层提供的。 一个重要的小技巧，也是许多发行版背后的推动力，就是只提供最基本的东西（就包装而言）。 这是因为它减less了攻击面。
chroot本质上是一个虚拟化的文件系统。 没有什么比这更less的了。 然而，普遍的误解是，如果有人可以“打破束缚”，那么他们也可以突破根基。
但是如何？ 首先，关于为什么“chroot是无价值的”的整个讨论是守护进程作为根运行可以妥协，以允许root权限升级。 但是大多数发行版以命名或绑定的用户身份运行Bind9。
因此，如果攻击者WAS妥协绑定，他将不得不扫描虚拟文件系统（chroot监狱）为可利用的应用程序，库，setuid可执行文件等，使用缓冲区溢出，或使用文件描述符等，和将有效载荷传送到基础系统中执行
如果使用正确 ，Chroot Jails可以正常工作
chroot背后的整个想法是提供运行Bind（在这个例子中）所需的绝对必要条件。 在一个chroot中运行多个应用程序并不是一个好主意，也不是将chroot用户放在jail中，而是将chroot实例绑定在一起。 这只会增加潜在的攻击面。
每个应用程序（特别是复杂的前向服务，需要input，直接与web进行通信）应该驻留在它自己的chroot监狱里。 你可以把所有的用户放在一个chroot监狱里，但为了尽量减less你的用户之间可能的攻击面（并提供更多的隐私），最好的select是让每个用户都在他自己的chroot监狱里。
最后，必须确保整个基地系统的安全。 这样，如果你在chroot监狱留下了一些可以利用的东西，他们必须在基本系统上妥协，才能够做出任何真正的损害（除了Bind和Chroot Jail之外）
通知我说你; 唯一可以对这个过程做出错误的人（因此使chroot监狱不安全）是你自己 。 有时坏的更新或零日利用目前出现漏洞，但大部分时间是其惯用的人为错误。
实施安全解决scheme的无能的人是一个真正的问题。
我对此的回应是，虽然这正是问题（人们对chroot的误解），但它已经适合用作安全解决scheme，并且多年来已被用于许多解决scheme（取得巨大成功）。 不是生活中的每件事物都被用于其预定的目的，而这显然是其中之一。
一个完美的例子是虚拟主机控制面板。 他们经常使用chroot来分隔用户。 此外，它在Dovecot，Sendmail，Apache / Mod_Security，OpenSSH等标题中也有工作实现，并且已经使用了许多库来提供安全性，其中一个例子是pam_chroot。
一个简单的search就会提高这个特性的可信度，把你的系统安全的意见build立在“错误认识的误解”上，这纯粹是无稽之谈，
不能chroot限制攻击者访问文件的一个子集，从而更难find一个特权升级的bug。 如果是这样，那么它可以用作安全工具。 相关阅读： http ： //www.openbsd.org/faq/faq10.html#httpdchroot