SELinux 在 Linux 系統上早已是廣為人知的存取控制機制，但也知名於令人卻步的學習曲線，因此系統管理員傾向使用社群所維護的開源 Policy，也就是所謂 Reference Policy，此 Policy 提供普遍系統詳細的存取控制規則，系統管理員以此為基礎並於其中調整至符合自身需求，但調整方法可能大都使用 audit2allow 來消除受阻擋訊息或是使用 chcon 來調整 subject/object 標籤名稱。此種 trial-and-error 的方式可能會導致 Policy 開啟了不必要的權限，因為缺乏人員檢視，而且也受限於檢視人員對於 SELinux 以及系統的全面了解。

多虧現今資安意識的普及和成長，經過安全與便利的權衡，大部分的人較願意接受輕量化的存取控制機制，例如應用程式白名單。此類機制會在應用程式執行時被系統偵測，檢視其是否屬於白名單內之程式，接着判斷允許或阻擋執行。此種簡易的概念贏得許多人支持，為了支持此概念，我們先捨棄 Reference Policy，並基於 SELinux 來從頭做出所謂 WhiteList Policy，我們的實驗表達出下列 3 個觀點。

1. 是 Policy 決定是否簡單使用與否，而不是 SELinux 機制。

2. 資安解決方案是從許多方面的觀點權衡而來，尤其是便利性與完全性。

3. 概念簡單的應用程式白名單也存在理論與實務的間隔。

我們花了幾個禮拜的時間在 Ubuntu 18.04 上建制 WhiteList Policy，起初直覺的將世界一分為二，白名單內與外，好與壞，能做任何事與不能做任何事，Policy 精簡到包含宣告只有10幾行規則，運行時被建立的新檔案預設被標籤為白名單外。很快的，我們在開機流程發現，處處存在着灰色空間，許多的應用程式會在運行時建立檔案並且執行它，例如 systemd 和 gnome-shell 在 /tmp 底下產生並使用許多暫時檔案，當然這些暫時檔案並不存在於白名單中，這也導致我們需要宣告一些新標籤。另外一方面，為了處理 script 執行情景，例如使用 pipe 或是 mmap 來執行惡意腳本，我們增加了新的 interpreter_t 標籤與規則來特意區別與處理 interpreter 程式。最後我們從原本的 2 個產生到了8個左右的標籤，也就是說我們至少描述 8x8 的規則數量。其中我們也發現一些應用 SELinux 功能的應用程式 hardcode 標籤在程式碼中，例如 dpkg_script_t。

從我們的實驗中可以得知 WhiteList Policy 的變化，從2個標籤到8個以上的標籤以及許多因應而生的存取控制規則，這些變化不斷朝向least privilege 的概念前進，都只是為了能讓系統正常的運作在白名單機制之下。