為什麼在 chroot 中運行 name(bind) 對於安全性如此重要？或者也許不是？

Question

我正在玩 bind，並開始想知道為什麼這個軟體在 CentOS 中以 chroot 運行。不要誤會我的意思，我知道什麼是bind，什麼是chroot（監獄）。但我的主要問題是，在沒有 chroot 的情況下運行 Bind 非常不安全嗎？

在沒有監獄的情況下設置它真的有害嗎（比任何其他服務或軟體更有害）。在系統中，有許多進程在沒有chroot 的情況下運行，我認為對它們中的任何一個進行妥協都是非常危險的，但是是什麼讓named 比其他在沒有chroot 的情況下運行的軟體更危險呢？

Answer 1

正如@Some Guy 所提到的，你必須從歷史的角度來思考這個問題。

從歷史角度來看，單一硬體是單一作業系統下十幾個不同的服務。如果一項服務受到損害，那麼該硬體上的所有內容都會受到損害。

透過虛擬化，這不再是一個問題。雖然逃離虛擬機器並非不可能，但這絕非微不足道。脫離虛擬機器肯定比以 root 權限執行的程序脫離 chroot 更困難。所以我的綁定伺服器在它們自己的虛擬機器上運行。在這種情況下，chroot 確實沒有多大意義，因為僅僅因為它是虛擬機，損害就已經受到限制。

chroot 是創建虛擬機器之類的東西的非常弱的嘗試。不過，任何具有 root 權限的程序都可以逃避 Chroot。 chroot 不是一種安全機制，也不能作為一種安全機制。帶有 BSD 監獄或 LXC 的 chroot 為您提供作業系統級虛擬化並提供安全功能。但如今，啟動整台機器的新虛擬機器變得如此容易，因此可能不值得花費精力進行設定或學習如何使用作業系統級虛擬化工具來實現此目的。

早期版本的bind 並沒有放棄特權。在Unix上，只有root帳戶可以打開1024以下的端口，眾所周知，Bind需要監聽udp/53和tcp/53。由於 Bind 以 root 身分啟動，並且不會放棄特權，任何妥協都意味著整個系統可能受到損害。如今幾乎所有軟體都會開始開啟它們的套接字並執行任何其他需要根權限的操作，然後它們會將正在執行的使用者變更為非特權帳戶。一旦放棄特權，受到損害對主機系統的影響就會大大降低。

Answer 2

其他答案都很好，但沒有提到分層安全的概念。您添加到系統中的每一層安全性都是對手必須克服的另一層。將 BIND 放入 chroot 又增加了一個障礙。

假設 BIND 中存在可利用的漏洞，並且有人能夠執行任意程式碼。如果他們處於 chroot 中，則需要先突破該狀態，然後才能存取系統中的其他內容。如前所述，破壞 chroot 需要 root 權限。 BIND 不以 root 身分運行，並且 chroot 中應該有最少的可用工具，進一步限制了選項，基本上只留下系統呼叫。如果沒有系統呼叫來提升權限，那麼攻擊者就只能查看您的 DNS 記錄。

正如 SomeGuy 所提到的那樣，上述情況不太可能發生，目前 BIND 的漏洞相當少，而且它們大多僅限於 DoS 類型的場景，而不是遠端執行。也就是說，在 chroot 中運行是相當多作業系統上的預設配置，因此您不太可能花費任何精力來保持稍微增強的安全性。

Answer 3

前言

我不斷聽到人們在網路上重申誤解..因此，我會盡力做出一些澄清

首先；有多少偶然的發現，這只是..由於因果，最終被用於某事其他比其預期目的？

Chroot 監獄曾經和現在是什麼

Chroot 最初設計用於更改進程或使用者的根目錄（非常適合從未知來源編譯軟體）。這提供了安全到基本系統，以及快速測試台設備，包括易於清理。多年過去了，它的概念和隱含用途也同樣改變了。

chroot 已被使用有效地，並且直接位於程式碼庫中一些程式和函式庫（即 openSSHd、apache2 + mod_security2/mod_chroot、dovecot、sendmail、openVPN、pam_chroot、還有更多）。假設所有這些主流應用程式都實施了錯誤的安全解決方案只是不對

chroot 是檔案系統虛擬化的解決方案：僅此而已。認為您可以輕鬆擺脫 chroot 的假設也是不正確的...只要您遵守 chroot 監獄內運行進程的準則即可。

確保 chroot 監獄安全的一些步驟

即是不是以 ROOT 形式運行進程。這可能會開啟一個根升級向量（在 chroot 內部或外部也是如此）。不運行進程裡面chroot，使用與另一個進程相同的用戶外部chroot。將每個進程和使用者分離到自己的 Chroot 中，以限制攻擊面並提供隱私。只掛載必要的文件、函式庫和設備。最後，chroot 並不能取代基本系統安全性。保護整個系統。

另一個重要說明：很多人認為 OpenVZ 已經失效，或是與完整系統虛擬化相比並不相同。他們做出這個假設是因為它本質上是一個 Chroot，具有已消毒的進程表。在硬體和設備上採取安全措施。最多您可以在 chroot 中實現它。

並非每個管理員都具備在專用伺服器或完整系統虛擬化下保護所有必要核心參數所需的知識水平。這意味著部署 OpenVZ 意味著您的客戶在部署應用程式之前需要嘗試、覆蓋和保護的攻擊面將大大減少。一個好的主機會很好地保護這些參數，反過來，這不僅對節點上或資料中心的每個人都有好處，而且對整個互聯網都有好處...

如上所述，chroot 提供檔案系統虛擬化。您必須確保不存在setuid 可執行檔、不安全的應用程式、庫、懸掛的無主符號連結等。 、使用檔案描述符，或以其他方式危害 chroot 內的某些內容 - 通常透過權限升級或將其有效負載注入基礎系統來逃離監獄。

如果發生這種情況，通常是由於更新錯誤、零日漏洞或慣用的人為錯誤。

為什麼仍然使用 chroot，而不是完整的系統虛擬化

考慮以下場景：您正在執行虛擬專用伺服器，主機節點執行 OpenVZ。你只需不能運行任何在核心層級運行的東西。這也意味著您無法使用作業系統虛擬化來分離進程並提供額外的安全性。因此，你必須為此目的使用 chroot。

此外，無論可用資源如何，chroot 在任何系統上都是可持續的。簡而言之，它的開銷是所有虛擬化類型中最少的。這意味著它對於許多低階盒子來說仍然很重要。

考慮另一種情況：您有 apache 在虛擬化環境中運行。你想分離每個用戶。透過 apache 的 chroot 新增（mod_chroot、mod_security 等）提供虛擬化檔案系統將是確保最終使用者之間最大隱私的最佳選擇。這也有助於防止情報收集，並提供另一層安全保障。

簡而言之，重要的是要實現安全層數。 Chroot 可能就是其中之一。並不是每個人和每個系統都有機會存取內核，因此，chroot仍然有一個目的。在許多應用中，完整的系統虛擬化本質上是矯枉過正的。

回答你的問題

我並不特別使用 CentOS，但我知道 Bind 現在會在操作之前放棄其權限。然而，我認為該綁定由於其攻擊向量和潛在漏洞的歷史而被chroot。

另外...自動 chroot 該應用程式比不更有意義，因為並非每個人都可以存取完整的系統/作業系統級虛擬化。從理論上講，這反過來又有助於為 CentOS 用戶群提供安全性：

作業系統提供者根本不會假設每個人都運行相同的系統。這樣，他們可以幫助提供額外的安全層...

這是有原因的很多應用程式都使用這個，以及為什麼顯然您的作業系統在預設情況下會這樣做：因為它被用作安全功能，並且它確實有效。如前所述，經過精心準備，這是潛在攻擊者必須克服的另一個障礙 - 大多數時候，僅限於對 chroot 監獄造成損害。

Answer 4

這部分是由於歷史原因，舊版的 Bind 有嚴重且頻繁的安全漏洞。我還沒有真正了解這個主題的最新情況，但我敢打賭，與過去的糟糕日子相比，它已經有了很大的改進。

另一個更實際的原因是，它通常部署在面向互聯網的角色中，因此，它容易受到更多攻擊、探測和一般惡作劇。

因此，正如安全問題上的經驗法則一樣：安全總比後悔好，特別是因為 chroot 的工作相對較少。