在 SUSE Linux 上建立自訂 AppArmor 設定文件

SUSE 於 2025 年 11 月 4 日發布了 SLES 16.0，其中 SELinux 取代 AppArmor 成為預設的強制存取控制框架。如果您的伺服器執行的是 SLES 16，請勿假定 AppArmor 已安裝或處於作用中狀態：在使用這些指令之前，請確認該部署支援的框架。以下步驟遵循 SUSE 的 SLES 15 SP7 AppArmor 文檔，其中 AppArmor 預設安裝並執行。

在 SLES 15 SP7 上，自訂應用程式的實用方法是aa-genprof建立初始設定文件，在投訴模式下運行應用程序，檢查每個已記錄的請求，然後確認設定檔是否生效。範例中使用了一個假設的可執行檔路徑/usr/local/bin/report-worker；請將其替換為您應用程式的實際可執行檔路徑。

開始之前

AppArmor設定檔是儲存在`.appArmor.conf`下的文字策略/etc/apparmor.d。該apparmor-utils軟體包提供分析工具。檢查主機並確定實際的可執行文件，包括systemd單元是否啟動了包裝器或子進程：

sudo aa-status
command -v aa-genprof
systemctl status apparmor
readlink -f /usr/local/bin/report-worker

在進行設定檔工作之前，用於確認 AppArmor 已啟動的命令的終端視圖範例。

SUSE 指出，在 SLES 15 安裝中，AppArmor 預設為啟用。如果缺少工具或完整的 AppArmor 設定文件，請使用以下命令安裝設定檔sudo zypper in -t pattern apparmor。如果 AppArmor 未激活，請在進行效能分析之前找出原因，而不是假設僅憑設定檔就能提供保護。設定檔與可執行檔路徑關聯；如果實際工作負載以其他二進位檔案運行，而對包裝器進行效能分析可能會導致重要進程不受限制。

建立並完善個人資料

啟動生成器。如果應用程式已在運行，請先停止應用程序，然後再啟動設定檔生成：
```
sudo systemctl stop report-worker
sudo aa-genprof /usr/local/bin/report-worker
```
aa-genprof 啟動範例可執行檔的學習設定檔的終端機範例視圖。

服務名稱僅為範例。請使用實際的單元名稱，或如果程式未執行，則省略停止命令。aa-genprof當不存在設定檔時，該命令會建立一個近似配置文件，將其置於學習模式，重新載入配置文件，並在日誌中標記。學習模式會記錄超出策略範圍的請求，但允許這些請求；這是一種暫時的學習狀態，而非強制執行狀態。
模擬實際應用場景。保持生成器運作。在另一個終端機中，啟動服務並執行代表性作業或功能：
```
sudo systemctl start report-worker
sudo journalctl -f
```
範例服務啟動的終端視圖，以及在學習模式下執行該服務時觀察其活動的示意圖。

測試範圍應涵蓋正常啟動、預期輸入輸出路徑、排程任務、錯誤處理以及應用程式啟動的任何輔助程式。設定檔只能學習測試期間產生的請求。請勿使用生產環境中的敏感工作負載來產生事件；安全的測試環境和代表性的測試資料更為理想。
仔細審查每個訪問請求。返回aa-genprof並按S掃描標記的日誌範圍。對於每個提示，判斷應用程式是否真的需要該檔案、功能或子程式轉換。僅允許最有效的路徑和權限。當抽象概念能夠準確涵蓋常見任務時，才接受它；僅當匹配的文件具有相同的信任和存取要求時才使用通配符。拒絕或跳過偶然或無法解釋的請求。

aa-logprof 的終端視圖範例，aa-logprof 是用於查看已記錄存取請求的互動式工具。

請特別注意執行請求。不受限制的轉換可能會讓子程序逃脫父進程的策略約束；僅在有合理的設計需求時才使用。新增合法規則後，重複練習和掃描週期。當設定檔涵蓋測試行為後，即可完成生成器。 SUSE 指出，完成新的aa-genprof學習週期通常會將設定檔置於強制執行模式。
檢查產生的策略。對於此範例路徑，SUSE 的命名約定會將可執行檔路徑中的斜線轉換為句點，從而產生/etc/apparmor.d/usr.local.bin.report-worker。請仔細檢查結果，不要將產生的規則視為自動安全：
```
sudo less /etc/apparmor.d/usr.local.bin.report-worker
```
終端機顯示開啟設定檔的示意圖，該檔案的名稱位於可執行檔路徑之後。

檢查設定檔是否指定了目標可執行文件，使用了必要的包含文件，並且僅授予應用程式實際需要的配置、資料、日誌、套接字和輔助程式的存取權限。避免為了/避免被拒絕而設定過於寬泛的規則，例如無限存取或整個可寫目錄樹。應用程式仍然依賴普通的 Unix 所有權和權限；AppArmor 只是增加了一個獨立的限制層。
明確設定目標模式。審核通過後，強制執行自訂程式的設定檔：
```
sudo aa-enforce /usr/local/bin/report-worker
```
aa-enforce 將設定檔的限制套用至範例程式的終端範例視圖。

如果生成器退出後您手動編輯了設定文件，請使用以下命令重新載入設定檔集sudo systemctl reload apparmor。 SUSE 文件重新載入時會重新掃描設定文件，而不會解除正在執行的進程的限制。重新啟動應用程式服務，以便新策略應用於其進程。

核實正在執行的申請

在設定檔處於強制執行模式時，再次執行相同的代表性任務。確認服務已啟動、讀取了預期的輸入、寫入了預期的輸出，並且能夠執行所需的輔助或網路操作。然後檢查設定檔狀態和最近的核心訊息：

sudo aa-status
sudo journalctl -k -g apparmor --since today

用於確認自訂設定檔已載入到強制模式下的狀態檢查的終端範例視圖。

驗證期間過濾內核日誌中 AppArmor 事件的終端範例視圖。

自訂可執行檔應顯示為已載入並處於強制執行模式。核心日誌中的 AppArmor 拒絕記錄會標識策略阻止的請求；請使用這些記錄來診斷真正的應用程式故障，而不是允許所有已記錄路徑的理由。對於合法的權限缺失，請執行 `appArmor config` sudo aa-logprof，查看建議，對規則進行小範圍更新，如果您手動編輯過，請重新加載，然後重新運行受影響的應用程式路徑。

對於需要持續運作且效能分析必須跨越重啟或更長時間觀察的服務，SUSE 提供了一套獨立的系統工作流程，該流程使用 `src` aa-autodep、aa-complain`src` 和重複aa-logprof掃描。如果學習運行可以保持開啟狀態以完成整個測試，則獨立aa-genprof方法更為簡單。兩種工作流程都無法推斷從未實際運行過的應用程式行為，因此當軟體或配置發生變更時，應持續審查效能分析結果。