為提供您更佳的服務,本網站使用 Cookies。當您使用本網站,即表示您同意 Cookies 技術支援。更多資訊請參閱隱私權聲明確定

Session
  • 5月 6日 星期四
  • 15:45 - 16:15
  • 7F 701G

OpenWrt 安全:缺少的拼圖

近幾年嵌入式設備因各種領域的智慧型裝置崛起而變的熱門,有些領域因成本結構考量,會使用現有的系統搭配上自家的調整與最佳化技術。OpenWrt 系統即是起源於 WiFi router 應用之中,它的優勢在於整合多種功能,能夠針對不同消費性產品來作調整,而且也透過減少或是修改一些功能帶來較少的記憶體足跡(例如 PAM authentication)。


有些嵌入式設備出廠後並沒有做後續更新,也因此易受到安全漏洞的影響,就連 OpenWrt 也無例外。雖然社群盡最大力氣去為 OpenWrt 帶來所謂縱深防護,但大多軟體套件只有少數人維護,對於此不足,來自 bootlin 的 Thomas Petazzoni 於 2019 試圖將 SELinux 機制帶入 OpenWrt,而他的成果也被社群所接受。


他的成果仍然位於早期移植階段,也就是 user-space 套件與相關的 kernel 選項,並沒有針對 OpenWrt 調整 Reference Policy。要了解的是 SELinux 的效用不只有單靠 SELinux 機制的運作,而是其所使用的 Policy 是否根據系統行為來進行限制。大多數人所使用的 Reference Policy 假設其運作在傳統 Linux 發行版本,如果 Policy 沒有根據系統行為來進行限制則無防護性可言。貢獻的人提議使用audit2allow來補足Policy不足的部分,但經過我們開始從頭研究 OpenWrt 發現,這是沒有用的,因為當 SELinux 防護開啟時竟然沒有任何的阻擋訊息,也就是說所有行為皆被允許。這個情況起因於執行主體的標籤為 init_t,此標籤擁有很大的權限。經過深入檢視後,我們發現 OpenWrt 與傳統 Linux 發行版本(例如 Debian )有許多的差別:

1. OpenWrt 的 init 程式稱為 procd,它融合了 device discovery 和系統服務管理的功能,類似於 systemd。

2. OpenWrt 預設上傾向於資源受限的實作方式,例如使用 dropbear 而不是 openssh 作為預設的 ssh server。

3. 許多的設備並無可寫的儲存原件,例如 Flash,單單只有載有 factory image 的 ROM 和所需運作的 RAM,因此 OpenWrt 被修改成 stateless 的狀態,透過掛載 tmpfs 到 /tmp 並建立 symbolic-linking 到 /var 上,開機所需的 /var/lock 目錄在運行時期被 preinit 和服務管理 script 建立。

4. OpenWrt 使用 ubus,一個簡化過的 Remote Procedure Call 機制,取代標準的 D-Bus 機制。許多關鍵的系統服務都依靠此機制來讓系統緊密運作,類似 Android binder。

以上這些差別使得 OpenWrt 獨樹一格,也因此無法完全與 Reference Policy 相容。

現今,因資安事件不斷,資安已是必須考量的問題,在 OpenWrt 上開啟 SELinux 無疑的為我們帶來更多的防護。然而,系統如果缺乏適合的 Policy 運作,將使得保護失效並帶來安全的錯覺。我們的實作填補了此縫隙,為系統帶來 SELinux 的防護,期望提供每個人更加安全的環境(prevention rather than mitigation)。

中階等級
Access Control Endpoint SecurityApplication Security
張柏駿

張柏駿

工業技術研究院 資通所 F 組工程師

現為工業技術研究院資通所 F 組工程師