bind9 在 chroot 監獄中 - 是否必要？
我總是將我的 bind9 安裝保存在 chroot 監獄中。現在我升級了我的 vServer 並且必須重新安裝 bind9。由於我的託管服務提供商使用的虛擬化解決方案，我無法自己創建設備（
/jail/dev/random和/jail/dev/null），我的託管服務提供商為此收取 20 歐元的費用。引用阿德里安·邦克的話，
實施安全解決方案的不稱職的人是一個真正的問題。Chroot 不是，也從來不是一個安全工具。人們已經基於 chroot 的屬性建構了一些東西，但經過了擴展（BSD jails，Linux vserver），但它們完全不同。
據我了解這個討論，在 chroot 中以 root 身份執行軟體毫無價值，因為 root 使用者總是可以越獄。但是如果我以非特權使用者的身份執行它，它仍然應該提供額外的安全性，對嗎？
總而言之，將 bind9 放入 chroot 監獄是否值得 20 歐元？
好吧，lkml 的討論是關於 root 使用者逃離 chroot 監獄，並且 bind 永遠不會使用 root 權限在 chroot 監獄中執行。因此，如果攻擊者破壞了綁定過程，他或她仍然必須找到一個漏洞來逃離 chroot 監獄。
我意識到這有點晚了，但就 chroot 而言，它不提供任何“真正的”安全性——
這是錯誤的！
安全的整個想法是它是分層提供的。一個主要的技巧，也是許多發行版背後的驅動力，是只提供最基本的東西（就軟體包而言）。這是因為它減少了攻擊面。
chroot 本質上是一個虛擬化文件系統。僅此而已，僅此而已。然而，普遍的誤解是，如果有人可以“打破綁定”，那麼他們也可以打破 chroot…
**但如何？**首先，關於為什麼“chroot 毫無價值”的整個討論是，以 root 身份執行的守護程序可以被破壞以允許 root 權限升級。但大多數發行版以使用者命名或綁定的身份執行 Bind9。
因此，如果攻擊者想要破壞Bind，他將不得不使用緩衝區溢出或文件描述符等來搜尋虛擬文件系統（chroot jail）以尋找可利用的應用程序、庫、setuid 執行檔等，並且將有效負載傳送到基礎系統中以供執行
如果使用得當，Chroot Jails 可以很好地工作
chroot 背後的整個想法是提供執行 Bind（在本例中）所需的絕對基本要素。在一個 chroot 中執行多個應用程序不是一個好主意，將 chroot 使用者與綁定的 chroot 實例*一起放在監獄中也不是一個好主意。*這只會增加潛在的攻擊面。
每個應用程序（特別是接受輸入的複雜前向服務，直接與 Web 通信）都應該駐留在自己的 chroot 監獄中。您可以將所有使用者置於一個 chroot 監獄中，但為了最大限度地減少使用者之間可能的攻擊面（並提供更多潛在的隱私），最好的選擇是將每個使用者同樣置於自己的 chroot 監獄中。
最後，必須保護整個基礎系統。這樣，如果您在 chroot 監獄中留下了可利用的東西，他們必須破壞基礎系統才能造成任何真正的損害（除了 Bind 及其 Chroot 監獄）
注意我說的是你；唯一可以讓這個過程出錯（因此使 chroot 監獄不安全）的人就是你自己。有時糟糕的更新或零日漏洞會出現漏洞，但大多數時候是慣用的人為錯誤。
實施安全解決方案的不稱職的人是一個真正的問題。
我對此的回應是，雖然這正是問題所在（人們濫用 chroot），但它已被改編為用作安全解決方案，並且多年來已在許多解決方案中使用（取得了巨大成功）。並非生活中的一切最終都被用於其預期目的，這顯然是其中之一。
一個完美的例子是虛擬主機控制面板。他們經常使用 chroot 來分隔使用者。此外，它在 Dovecot、Sendmail、Apache/Mod_Security、OpenSSH 等標題中都有工作實現，並且已被許多庫用於提供安全性，例如 pam_chroot。
一個簡單的搜尋就會發現這樣一個特性的可信度，而將您的系統安全性的觀點建立在“對誤解的誤解”之上是無稽之談