
我正在分析一些專有軟體,以建立一組權限要求和 SELinux 策略,以允許其在 Oracle Linux(或任何 RHEL 衍生產品)上安裝和運行。
我在寬容模式下運行 SELinux,我已運行 semodule -DB 來停用“dontaudit”,並且我正在查看 /var/log/audit/audit.log 以查看結果。
然而,我還希望看到允許的一切(不僅僅是拒絕或審核允許),據此判斷,這似乎是大多數:
[root@aw-selinuxtest ~]# seinfo --stats
Statistics for policy file: /etc/selinux/targeted/policy/policy.24
Policy Version & Type: v.24 (binary, mls)
Classes: 81 Permissions: 237
Sensitivities: 1 Categories: 1024
Types: 3852 Attributes: 291
Users: 9 Roles: 12
Booleans: 228 Cond. Expr.: 268
Allow: 311381 Neverallow: 0
Auditallow: 133 Dontaudit: 0
Type_trans: 38576 Type_change: 38
Type_member: 48 Role allow: 19
Role_trans: 368 Range_trans: 5601
Constraints: 90 Validatetrans: 0
Initial SIDs: 27 Fs_use: 24
Genfscon: 84 Portcon: 471
Netifcon: 0 Nodecon: 0
Permissives: 91 Polcap: 2
有誰知道如何做到這一點?到目前為止我正在努力尋找答案。
答案1
與通常的做法相反,將 SELinux 設定為permissive
模式並記錄所有 AVC 拒絕以開發策略模組可能會導致此類策略中包含錯誤的權限集。
一個例子如下:假設該專有軟體的正常操作需要域轉換,在寬容模式下,轉換不會發生,看起來源域需要記錄為 AVC 拒絕的所有權限(Sven Vermeulen 的 SELinux 食譜包含對此潛在問題的多次引用)。
為專有軟體建立策略模組的更好方法是先將 SELinux 維持在強制模式下,以確保最小特權可能正在被授予。
接下來是線上(有文件嗎?)和離線(、、、...)研究軟體,以ss
確定詳細的架構設計,即但不限於:strace
ipcs
文件,也應該分為子組(配置、交易、日誌…)
進程、服務(該軟體是否有 systemd/upstart/init 腳本?)
網路連線(入站和出站流量、連接埠...)
使用者、群組
有了所有這些信息,您就可以開始為該軟體製定策略。
您將需要:
建立一個 filecontexts 文件,定義所有涉及的文件的安全上下文
建立一個介面文件,根據文件、進程、連接埠、使用者、網域轉換等之間的所有互動來定義您的網域
建立一個類型強製文件,描述哪些使用者被授予存取上述網域的權限以及實際規則
編譯並載入它,檢查 AVC 拒絕,調試並增強您的策略。沖洗並重複。
從上面提到的書中,最後引用一句:
一些策略開發人員喜歡運行應用程式許可模式(透過在許可模式下運行整個系統或將此特定網域標記為許可域)、註冊所有執行的存取(透過 AVC 拒絕)並基於該資訊增強策略。儘管這可能會提供更快的工作策略,但這些開發人員也將面臨向策略添加太多特權的風險,而這是以後很難挑戰和更改的。相反,我們讓 SELinux 阻止訪問並查看應用程式的反應。根據應用程式的錯誤日誌記錄或應用程式的行為以及透過日誌看到的 AVC 拒絕,我們可以很好地了解真正需要哪些權限。