如何在 SUSE SLES 15 上為自訂應用程式設定 AppArmor 設定檔

版本說明（2026 年 10 月 6 日核實）：此步驟適用於使用 AppArmor 的 SUSE Linux Enterprise Server (SLES) 15 SP7 和相容的 SLES 15 系統。 SUSE 文件顯示，AppArmor 預設安裝在 SLES 15 SP7 上並運作。 SUSE Linux 16.0 移除了 AppArmor 並改用 SELinux，因此請勿將以下命令套用至 16.0 版本；請參閱 SUSE 的SUSE Linux 16.0 比較指南以及該版本的 SELinux 文件。

AppArmor 是一個 Linux 安全模組，用於限製程式可以存取的內容。設定檔是附加到可執行檔的策略：它可以允許或拒絕存取檔案、功能和其他資源。本指南將引導您從確認平台到強制執行經過測試的配置文件，並包含一個謹慎的學習階段，從而降低自訂應用程式意外崩潰的可能性。

建立個人資料前應該準備些什麼？

如果應用程式非常重要，請使用測試或維護視窗。您需要一個管理員帳戶sudo，應用程式的實際可執行路徑，以及它執行的常規任務清單。這些任務應包括後台運行、啟動和關閉、配置重新載入、上傳或匯出、排程任務以及任何連網功能。僅憑一次啟動取得的設定檔無法推斷出您從未執行過的功能。

了解應用程式的資料讀寫位置、運行它的帳戶以及它是否啟動輔助進程。盡可能避免使用敏感的生產數據進行測試。記錄目前服務狀態，並在進行任何變更之前保留現有設定檔的副本。

如何確認 AppArmor 在此 SUSE 版本中可用？

首先檢查作業系統版本和目前 AppArmor 狀態：

cat /etc/os-release
sudo aa-status

確認系統報告的版本為 SLES 15 SP7 或其他文件支援 AppArmor 的版本。 SUSE 指南指出，在 SLES 15 SP7 上，AppArmor 預設已安裝並執行。如果未安裝，SUSE 文件中提供了安裝說明sudo zypper in -t pattern apparmor。如果該服務已安裝但未運行，請在啟用它之前檢查系統的啟動策略和服務狀態；切勿為了解決應用程式問題而停用安全模組。有關特定版本的詳細信息，請參閱SLES 15 SP7 AppArmor 入門指南和SLES 15 SP7 AppArmor 命令列工具指南。

如何確定 AppArmor 應該分析的可執行檔？

AppArmor設定檔與程式路徑關聯，因此需要識別實際的可執行文件，而不是假設使用者輸入的命令就是該二進位檔案。對於可透過shell路徑存取的命令，請執行：

command -v myapp

對於某項服務，請使用系統上可用的工具檢查其單元定義和進程詳細資料。啟動腳本、符號連結或解釋器可能會導致指向與預期不同的可執行檔。在readlink -f /path/to/myapp適當情況下，請使用已知路徑解析服務。請在下面的每個命令中替換為已驗證的絕對路徑；/usr/local/bin/myapp此處僅為範例。

在進行效能分析之前，請檢查 `/etc/suse/profiles` 目錄下是否已存在對應的設定檔。 SUSE 將設定檔儲存在該目錄下/etc/apparmor.d，檔案名稱通常會將可執行檔路徑中的斜線替換為點號。例如，`/ etc/suse/profiles` 會對應/usr/local/bin/myapp到類似 `/ etc/suse/profiles ...usr.local.bin.myapp/usr/share/apparmor/extra-profiles

如何安全地產生初始使用者畫像？

以管理員身份執行設定檔產生工具，並使用完整的可執行檔路徑：

sudo aa-genprof /usr/local/bin/myapp

aa-genprof建立初始設定文件，並在您測試程式時將其置於“投訴模式”。 「投訴模式」會記錄策略違規行為，但不會阻止被拒絕的操作，這使您可以在強制執行策略之前觀察程式的行為。請按照工具的提示操作；測試應用程式後，使用其掃描選項查看已記錄的事件。 SUSE 將此過程描述為迭代過程，並不能保證自動建議的設定檔是完整的。

應該測試哪些操作，在哪裡會遇到拒絕？

當設定檔處於投訴模式時，請像正常操作員一樣使用應用程式。測試常規工作流程和不常用但支援的任務，包括讀取、寫入、上傳、產生報告、重新啟動服務以及輔助作業。確保測試內容貼近實際：程式匯出時使用的檔案或子進程可能與主螢幕不同。

查看內核訊息和審計日誌中的 AppArmor 事件：

sudo journalctl -k | grep -i apparmor

根據系統日誌配置，SUSE 也會指向/var/log/audit/audit.log`<log_view_name> journalctl | grep -i apparmor`、`<log_view_name>` 和 ` dmesg -T<log_view_name>`。在某個日誌檢視中缺少符合項目並不能證明設定檔正確：請驗證應用程式是否已執行，並檢查日誌服務和其他已記錄的日誌位置。不要因為應用程式啟動了一次就認為生成的設定檔已測試過。

如何審核和完善個人資料？

以 root 使用者身份，使用該aa-logprof指令處理已記錄的事件並回答提示：

sudo aa-logprof

對於每個事件，都要詢問該存取權限是否是已記錄的應用程式任務所必需的。僅允許程式所需的特定路徑、存取模式或功能。讀取設定檔是預期之內的；對無關目錄的非計劃寫入可能表示有錯誤或需要調查的獨立元件。規則過於寬泛會削弱限制，而規則過於狹窄則可能破壞有效的任務。

• 不要自動接受所有提示或授予所有檔案的通用存取權限。
• 避免使用寬泛的通配符和不必要的功能；盡量使用精確的路徑和最小的所需權限。
• 設定檔修改後，重複工作負載和日誌審核週期。包括單獨的服務操作和後台任務。
• 更改範圍應僅限於目標應用程式；不要為了消除乾擾而進行無關的設定檔編輯。

此設定檔是存取控制邊界，因此對提示的回應應基於應用程式行為和操作要求，而不僅僅是因為它出現在日誌中。 SUSE SLES 15 SP7 AppArmor 命令列工具指南解釋了命令列工具，SUSE AppArmor 支援參考連結指向相關的 man 手冊頁，包括aa-genprof、aa-logprof和apparmor_parser。

何時應該切換到強制模式？

只有在代表性工作流程成功運作且您已審核過合法事件後，才能執行策略。強制執行單一應用程式設定文件，重新載入 AppArmor 的設定檔集，然後重新啟動應用程式或服務，以便執行中的進程使用更新後的策略：

sudo aa-enforce /usr/local/bin/myapp
sudo systemctl reload apparmor

SUSE 指出，重新載入會重新讀取設定檔/etc/apparmor.d；已執行的程式可能需要重新啟動才能使更新後的設定檔生效。請與服務所有者協調重啟事宜，並使用正確的應用程式服務管理命令。然後，在強制執行的前提下重複關鍵工作流程，而不是假設在「投訴模式」下成功就意味著它們無需任何更改即可正常工作。

如何驗證結果並從迴歸中恢復？

測試後，檢查個人資料狀態並尋找新的拒絕記錄：

sudo aa-status
sudo journalctl -k | grep -i apparmor

確認目標設定檔已載入並處於強制執行模式，服務運作正常，且所有必要任務均可正常運作。如果強制執行阻止了合法操作，請收集相關事件，檢查存取權限是否真正必要，並縮小設定檔的範圍。為了進行簡短、可控的診斷，sudo aa-complain /usr/local/bin/myapp可以將該程式的設定檔置於投訴模式；進行調查、更新和重新測試，然後再將其恢復為強制執行模式aa-enforce。根據需要重新載入並重新啟動。避免為了快速解決問題而全域關閉 AppArmor 或授予過大的權限。

你應該避免哪些常見錯誤？

• 使用錯誤的發布說明：此處的流程適用於 SLES 15 AppArmor。根據 SUSE 的對比指南，SUSE Linux 16.0 使用的是 SELinux。
• 分析的是包裝器而不是真正的程式：驗證實際運行的可執行文件，特別是對於服務和腳本。
• 學習不足：未經測試的功能不會產生觀察到的訪問，因此不完整的分析可能會在以後失敗。
• 批准提示時缺乏上下文：每個新增權限都應該服務於必要的應用程式任務。
• 忘記重啟：重新載入設定文件，然後在需要時重新啟動正在運行的應用程序，以便該進程採用該策略。
• 編輯時沒有回滾路徑：備份本機維護的設定文件，並在版本控製或系統配置管理過程中追蹤變更。

SUSE 官方參考資料

• SLES 15 SP7 AppArmor 入門指南
• SLES 15 SP7 AppArmor 命令列工具指南
• SUSE設定檔庫文檔
• SUSE AppArmor 支援參考
• SUSE Linux 16.0 對比指南

這些參考資料已於 2026 年 10 月 6 日核實。命令和軟體包詳情可能會因產品版本而異；在進行任何更改之前，請確認已安裝的確切 SLES 服務包的文件。