我們有一台裝有Alma Linux 9.3作業系統的伺服器。預設（以及目前所有類似 RHEL 的作業系統）它已fapolicyd啟用。該伺服器上還運行著一個應用程式伺服器（WildFly/JBoss/Java）。部署的應用程式處理一些資料檔案（由使用者提交），並且在標準情況下運作正常。
然而目前，有一段時間應用程式需要每分鐘處理 1000 個左右的檔案。在這種情況下，fapolicyd開銷佔用了約 15% 的 CPU，我們認為該開銷過高。
我在網路上找不到有類似問題的人。
fapolicyd我也很驚訝ServerFault 上沒有標籤。
問題：
- 有沒有一種方法可以優化
fapolicyd配置，以便它可以更快地決定是允許還是拒絕文件存取？- 我想到的一件事是自訂規則的排序。
- 也許使用通配符與使用文字規則。
- 有什麼提示如何評估
fapolicyd對我們來說有多重要嗎？- 我們是否可以將其關閉，或者儘管開銷巨大，但讓它運行是否確實是一個好主意。
- 其他發行版是否也使用類似的東西
fapolicyd，或者它是否「只是額外的安全性」就SELinux足夠了。 （我知道它們不一樣。）
資料來源：
答案1
允許列出已執行的程序是最有效的安全功能之一。如果沒有它，受損的使用者帳戶就可以執行任何任意有效負載。或者使用者將不應該安裝的程式安裝到其主目錄中。儘管它是一項可選功能，您可以決定啟用或不啟用。
檢查所有此類檔案系統呼叫會對效能造成影響。儘管可以透過優化規則和資料庫來最小化開銷。
從使用者的角度衡量效能是否可以接受。以回應時間為中心的目標，例如“99.9% 的應用程式 API 呼叫將在 1 秒內完成”，將檢測到真正的問題，而不僅僅是資源利用率的趨勢。
首先了解 fapolicyd 的一些背景，請注意來自的效能介紹自述文件:
表現
當程式開啟檔案或呼叫 execve 時，該執行緒必須等待 fapolicyd 做出決定。為了做出決定，fapolicyd 必須查找有關進程和正在存取的檔案的資訊。 fapolicyd 的每個系統呼叫都會降低系統速度。
為了加快速度，fapolicyd 會快取它查找的所有內容，以便後續存取使用緩存，而不是從頭開始查找。但緩存就這麼大。不過，你可以控制它。您可以增大主題和客體快取。當程式結束時，它將像這樣輸出一些效能統計資料到 /var/log/fapolicyd-access.log 或螢幕中：
Permissive: false q_size: 640 Inter-thread max queue depth 7 Allowed accesses: 70397 Denied accesses: 4 Trust database max pages: 14848 Trust database pages in use: 10792 (72%) Subject cache size: 1549 Subject slots in use: 369 (23%) Subject hits: 70032 Subject misses: 455 Subject evictions: 86 (0%) Object cache size: 8191 Object slots in use: 6936 (84%) Object hits: 63465 Object misses: 17964 Object evictions: 11028 (17%)在此報告中，您可以看到內部請求佇列最大為 7。這表明它得到了一些備份，但處理請求的速度非常快。如果這個數字很大，例如超過 200，那麼可能需要增加 q_size。請注意，如果超過 1015 個，則可能需要告訴 systemd 允許超過 1024 個描述符。在 fapolicyd.service 檔案中，您需要新增 LimitNOFILE=16384 或大於佇列的某個數字。
另一個值得關注的統計數據是點擊率與驅逐率。當請求無處放置訊息時，它必須逐出某些內容以騰出空間。這是透過 LRU 快取完成的，它自然地確定哪些內容未被使用，並使其記憶體可供重複使用。
上述統計中，主題命中率為95%。物件緩存就沒那麼幸運了。為此，我們的命中率為 79%。這仍然很好，但還可以更好。這表示對於該系統上的工作負載，快取可能會更大一些。如果用於快取大小的數字是素數，則與具有公分母的情況相比，由於衝突而導致的快取變更會更少。您可能會考慮的快取大小的一些質數是：1021、1549、2039、4099、6143、8191、10243、12281、16381、20483、24571、28669、32687、40961、499、4939、4991
另外，應該要提到的是，策略中的規則越多，它需要迭代的規則就越多才能做出決定。至於系統效能影響，這很大程度取決於工作負載。對於典型的桌面場景，您不會注意到它正在運行。在短時間內開啟大量隨機檔案的系統會產生更大的影響。
另一個可能影響效能的配置選項是完整性設定。如果將其設為 sha256，則物件快取中的每次未命中都會導致對正在存取的檔案計算雜湊值。一種權衡是使用大小檢查而不是 sha256。這並不安全，但如果效能有問題，這是一個選擇。
do_stat_report = 1在 config 中啟用統計報告，然後重新啟動 fapolicyd（如果最近沒有）。分析/var/log/fapolicyd-access.log 並記錄哪些 PID 開啟哪些檔案的模式。
注意“命中”與“未命中”的比率。命中率越高越好，存取記憶體資料庫比檔案系統存取和處理要快得多。增加obj_cache_size系統同時擁有的文件數量的配置。可能的上限是資料檔案系統中已使用的 inode 數量（如df -i輸出所示）。這可能過多，但如果您有足夠的內存，為什麼不緩存幾十萬個條目。
檢查 fapolicyd.conf 中的配置。integrity除none或之外的值size將計算校驗和並具有開銷。特別是如果您在處理新文件時出現大量失誤，這可能會佔用大量 CPU。q_size應該大於訪問報告上的“最大隊列深度”，但是我懷疑是否需要增加隊列大小。
檢查規則，在來自rules.d的compiled.rules。 RHEL 和 Fedora 從 rpm 填充可信任文件，不允許執行未知文件，不允許 ld.so 技巧，並允許大多數開啟。如果您確實修改規則，請考慮在開啟的系統呼叫等待時執行更多操作對效能的影響。
像往常一樣，您可以在故障排除時分析到底發生了什麼。 perf top將列印 CPU 上的功能，並且在安裝了 debuginfo 時效果更好。 bcc-tools 套件有一些簡潔的腳本：opensnoop 和 execsnoop 來即時列出 open 和 exeve 呼叫。
最終，您決定採取哪些控制措施以僅允許執行未經授權的程序。在 exec 呼叫中立即允許列表，就像 fapolicyd 一樣，當然非常強大。一個不太全面的替代方案可能是限制 shell 存取：不允許人們互動 shell，並鎖定主目錄的權限。或者，如果資料檔案系統根本不應該有任何程序，請考慮將其掛載為 noexec。良好的安全審計不會將清單視為一成不變，而是列出適當的替代控制措施及其原因。