“Sandbox” 是系統安全用的術語,有兩個意義:
放在某些虛擬防護牆裡的執行程序,這些防護牆是用來阻止 某些人侵入這道程序,進而出入於更大的系統中。
這道程序可以完全在防護牆裡 “動作”。也就 是說,它所執行的任何程式不可能會滲透到牆的外面。所以如果 您對它有安全上的顧慮,並不需要特別去監聽它的一舉一動,反 正它只能在牆內活動。
舉例來說,可以用 userid 來做這道防護牆,這正是 security 和 named 說明文件中的定義。
現在就用 ntalk 這個服務作說明(見 /etc/inetd.conf)。這個服務以前的 userid 是 root,現在執行時則是用 tty。tty 這個使用者就是一個 sandbox,如果有人能夠順利用 ntalk 侵入系統,現在他就算進得來也只能用這個 userid。
放在某個模擬機器裡的程式,這比上述來得更嚴密。基本上 這表示能侵入該程式的人相信他能再進入所屬的機器,但事實上 只會進入模擬出來的機器,無法進一步修改任何真實的資料。
達到這個目的最常用的方法,就是在某個子目錄下做出模擬的 環境,然後用 chroot 執行該程式,這樣該程式的根目錄便是這個 子目錄,而非系統真正的根目錄。
另一個常見作法是將某個檔案系統 mount 成唯讀,但在它 上面另外製造出程式以為可以寫入的檔案系統。這個程式會相信 它可以對其他檔案讀寫,但只有它看不到這個唯讀效應 - 系統 執行的一般程式都看得到。
我們試圖將這類 sandbox 盡量透明化,讓使用者或侵入者 無法看到他是否在某個 sandbox 裡面。
UNIX 實作兩種 sandbox,一個在程式層面,另一個則是由 userid 來達成。
每個 UNIX 執行程序會用防火牆將它和所有其他程序隔開,某個程序 不可以隨意修改其他程序位址的資料。這和 Windows 中,程式可以輕易 修改其他位址資料,結果導致當機的情形大不相同。
每個 UNIX 程序都屬於某個特定的 userid。如果該 userid 不是 root,就會將它和其他使用者的程序隔開。 Userid 同時也用於硬碟資料的存取權上。
securelevel 是核心中所實作的一個安全機制。基本上當 securelevel 是正值時,核心會限制某些工作;即使是 superuser (也就是 root) 也無法完成那些工作。在撰寫 本文時,securelevel 機制在一般的限制外,還能夠限制以下的功能:
清除某些特定的檔案旗標,例如 schg (系統唯讀標旗, the system immutable flag)
經由 /dev/mem 與 /dev/kmem, 將資料寫入至核心記憶體中
載入核心模組
更動 ipfirewall(4) 規則。
想要檢查在某個運作中的系統的 securelevel 狀態,只要執行以下 命令即可:
# sysctl kern.securelevel
輸出的結果會包含一個 sysctl(8) 變數名稱
(在這個例子中, 它是 kern.securelevel
)
以及一個數字。後者即是 目前的 securelevel 值。如果它是一個正值 (也就是大於 0),表示至少
有一些 securelevel 的保護機制已經開啟了。
你沒有辦法降低一個運作中的系統的 securelevel;如果可以的話,
就失去了這個機制的意義了。如果你要作一些需要 securelevel 為 非正值才可以的動作的話 (例如
installworld 或更動日期),你需要修改 /etc/rc.conf 內的 securelevel 設定 (找找 kern_securelevel
和 kern_securelevel_enable
變數),然後重新開機。
想要知道更多有關於 securelevel 與各個不同等級影響的細節, 請參考 init(8) 說明文件。
警告securelevel 可不是萬靈丹;它有許多已知的缺陷,往往造成 一種安全的假象。
它一個最大的問題,就是要讓這個功能完全有效的話,在 securelevel 發揮作用前的啟動過程中,所有使用到的檔案都 必須被保護起來。如果一個攻擊者在 securelevel 有效前 (由於 有些系統在啟動中所作的事情,無法在較高的 securelevel 中 正常運作,所以這會在啟動過程中後期才會運作),能讓他們的程式 被執行的話,securelevel 的保護就完全無效了。保護啟動程序 中所有的檔案在技術上是可行的,但是如果真的這樣作的話,系統 維護將會變成一場夢魘。即使只是修改一個設定檔,也必須將整個 系統關閉,至少也得到單人模式。
除了這點,還有許多其它的東西都在通信論壇上討論,尤其是 freebsd-security。請到 這裡 搜尋以前的 討論。有些人希望 securelevel 能夠儘快消失,由另一個更優秀的 機制取代,不過機會有點渺茫。
風險自行承擔。
FreeBSD 3.0 後的版本使用一個特殊的 BIND 版本,這個版本會使 用隨機的高編號通訊埠來回應外部的查詢。如果你因為要適合防火牆的 設定或是單純的想讓自己看來舒服一點而想用 53 通訊埠回應外部查詢, 那麼你可以嘗試更改以下檔案相關內容 /etc/namedb/named.conf:
options { query-source address * port 53; };
你也可以將 * 更改為特定 IP address, 藉以加強控制條件。
順便恭喜你。能夠讀取你系統上的 sockstat(1) 報告並且注意 不正常狀況是一件好事!
較新版本的 Sendmail 支援 mail submission 這項功能,並且使 用通訊埠 587。這項功能還沒有被廣泛支援但是支援的數目正在增長 中。
放心。toor 是一個 “alternative” 管理者帳號 (toor 是 root 的轉向拼法)。 以往是跟隨 bash(1) 安裝而建制的,後來則成為系統內定建制的一 個帳號。這個帳號將伴隨一個非標準的 shell 測試使用, 讓你不需要去 更改到 root 的內建 shell。因為這些其他的 shell 並沒有跟隨系統預設值安裝 (舉例來說,某些由 ports 安裝的 shell package),而被內定安裝在 /usr/local/bin 目錄下,有可能存在不同的檔案系統中。 倘若 root 的 shell 被放在 /usr/local/bin,且 /usr (或是其他包含著 /usr/local/bin 這個子目錄的檔案系統) 因為某些原因並沒有被正常的 mount 起來的話,root 將無法正常的登入系統進行維修 (雖然說你重開機成單人模式就會問你要 載入哪個 shell)。
有些人使用 toor 帳號進行每日的 root 維護工作,如此可以使用非標準的 shell,而 root 可以保留標準 shell, 以因應單一使用者模式 (single user mode) 或緊急狀況處理。 依照系統內定值,你將無法使用 toor 登入, 因為這個帳號尚未更改密碼設定。因此你如果你想啟動這個帳號,你需要 使用 root 登入系統並且修改 toor 的密碼。
本文及其他文件,可由此下載:ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/。
若有 FreeBSD 方面疑問,請先閱讀 FreeBSD 相關文件,如不能解決的話,再洽詢
<questions@FreeBSD.org>。
關於本文件的問題,請洽詢 <doc@FreeBSD.org>。