近幾年嵌入式設備因各種領域的智慧型裝置崛起而變的熱門，有些領域因成本結構考量，會使用現有的系統搭配上自家的調整與最佳化技術。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)。