バージョンに関する注記（2026年10月6日確認）：この手順は、AppArmorを使用するSUSE Linux Enterprise Server（SLES）15 SP7および互換性のあるSLE 15システムに適用されます。SUSEは、SLES 15 SP7にAppArmorがデフォルトでインストールされ、実行されていることを文書化しています。SUSE Linux 16.0ではAppArmorが削除され、代わりにSELinuxが使用されるため、以下のコマンドをバージョン16.0に適用しないでください。SUSEのSUSE Linux 16.0比較ガイドおよび当該リリースのSELinuxドキュメントを参照してください。
AppArmorは、プログラムがアクセスできる範囲を制限するLinuxセキュリティモジュールです。プロファイルとは、実行ファイルに適用されるポリシーであり、ファイル、機能、その他のリソースへのアクセスを許可または拒否することができます。このガイドでは、プラットフォームの確認からテスト済みのプロファイルの適用までを、慎重な学習フェーズを経て解説します。これにより、カスタムアプリケーションが予期せず動作しなくなる可能性を低減します。
アプリケーションが重要な場合は、テストまたはメンテナンス期間を使用してください。管理者アカウントsudo、アプリケーションの実際の実行可能パス、およびアプリケーションが実行する通常のタスクの一覧が必要です。バックグラウンド処理、起動とシャットダウン、構成の再読み込み、アップロードまたはエクスポート、スケジュールされたジョブ、およびネットワーク接続機能を含めてください。1回の起動から学習したプロファイルでは、使用しない機能を推測することはできません。
アプリケーションがデータの読み書きを行う場所、実行アカウント、およびヘルパープロセスを開始するかどうかを把握してください。可能な限り、機密性の高い本番データに対するテストは避けてください。変更を加える前に、現在のサービスの状態を記録し、既存のプロファイルのコピーを保存してください。
まず、オペレーティングシステムのリリースバージョンと現在のAppArmorの状態を確認してください。
cat /etc/os-release
sudo aa-status
システムが SLES 15 SP7 または AppArmor をサポートするドキュメントを持つ別のリリースを報告していることを確認してください。SLES 15 SP7 では、SUSE ガイドによると AppArmor はデフォルトでインストールされ、実行されています。インストールされていない場合は、SUSE は を使用したインストール方法をドキュメントにsudo zypper in -t pattern apparmor記載しています。サービスがインストールされているが実行されていない場合は、有効にする前にシステムの起動ポリシーとサービスの状態を確認してください。アプリケーションの問題を回避するためにセキュリティ モジュールを無効にしないでください。リリース固有の詳細については、 SLES 15 SP7 AppArmor 入門ガイドおよびSLES 15 SP7 AppArmor コマンドライン ツール ガイドを参照してください。
AppArmorプロファイルはプログラムパスに関連付けられているため、ユーザーが入力したコマンドがバイナリであると想定するのではなく、実際の実行可能ファイルを特定してください。シェルパスからアクセスできるコマンドの場合は、以下を実行します。
command -v myapp
サービスについては、システムで利用可能なツールを使用して、そのユニット定義とプロセスの詳細を確認してください。ランチャースクリプト、シンボリックリンク、またはインタープリタによって、想定とは異なる実行可能ファイルが生成される場合があります。readlink -f /path/to/myapp適切な箇所で、既知のパスを解決してください。以下のすべてのコマンドで、検証済みの絶対パスを置き換えてください。/usr/local/bin/myappは単なる例です。
プロファイリングを行う前に、 の下にプロファイルが既に存在するかどうかを確認してください/etc/apparmor.d。SUSE はプロファイルをそこに保存し、ファイル名は通常、実行可能パスのスラッシュをドットに置き換えます。たとえば、/usr/local/bin/myappは のようなファイル名にマッピングされますusr.local.bin.myapp。既存のベンダープロファイルまたはローカルで管理されているプロファイルを、確認せずに上書きしないでください。SUSE は の下に追加のプロファイルもリストしています/usr/share/apparmor/extra-profiles。適切なプロファイルが開始点となる可能性がありますが、アプリケーションとリリースに合わせて確認する必要があります ( SUSE プロファイル リポジトリのドキュメント)。
プロファイル生成ツールを管理者として実行し、実行可能ファイルの完全なパスを指定してください。
sudo aa-genprof /usr/local/bin/myapp
aa-genprof起動プロファイルを作成し、実行中はプログラムをコンプリーモードにします。コンプリーモードではポリシー違反が記録されますが、拒否された操作はブロックされないため、強制適用前に動作を確認できます。ツールの指示に従ってください。アプリケーションの実行後、スキャンオプションを使用してログに記録されたイベントを確認してください。SUSE はこれを反復プロセスと説明しており、自動的に提案されたプロファイルが完全であることを保証するものではありません。
プロファイルが苦情モードになっている間は、通常のオペレーターと同じようにアプリケーションを使用してください。読み取り、書き込み、アップロード、レポート生成、サービス再起動、ヘルパージョブなど、通常のワークフローと、頻度は低いもののサポートされているタスクをテストしてください。テストは現実的なものにしてください。プログラムは、エクスポート時とホーム画面時で異なるファイルや子プロセスを使用する場合があります。
AppArmorイベントに関するカーネルメッセージと監査ログを確認してください。
sudo journalctl -k | grep -i apparmor
システムのログ設定によっては、SUSE は/var/log/audit/audit.log、journalctl | grep -i apparmor、 も参照しますdmesg -T。いずれかのログ ビューで一致が見つからなくても、プロファイルが正しいとは限りません。アプリケーションが実行されたことを確認し、ログ サービスやその他の文書化されたログの場所を確認してください。アプリケーションが一度起動したというだけで、生成されたプロファイルがテスト済みであるとみなさないでください。
root権限で、aa-logprofログに記録されたイベントを処理し、プロンプトに応答するには、以下を使用します。
sudo aa-logprof
各イベントについて、そのアクセスが文書化されたアプリケーションタスクに必要かどうかを判断してください。プログラムが必要とする狭いパス、アクセスモード、または機能のみを許可してください。設定ファイルの読み取りは想定内の動作ですが、無関係なディレクトリへの予期せぬ書き込みは、エラーまたは調査が必要な別のコンポーネントの存在を示している可能性があります。ルールが広すぎると制限が弱まり、狭すぎると有効なタスクが中断される可能性があります。
プロファイルはアクセス制御の境界であるため、プロンプトはログに表示されたという理由だけでなく、アプリケーションの動作と運用要件に基づいて回答する必要があります。SUSE SLES 15 SP7 AppArmor コマンドラインツールガイドでは、コマンドラインツールについて説明しており、SUSE AppArmor サポートのリファレンスaa-genprofには、、、aa-logprofなどの関連する man ページへのリンクがありますapparmor_parser。
代表ワークフローが成功し、正当なイベントを確認した後でのみ、ポリシーの適用を開始してください。アプリケーションプロファイルを1つ適用し、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 を全体的に無効にしたり、広範な権限を付与したりすることは避けてください。
これらの情報は2026年10月6日に確認されました。コマンドやパッケージの詳細は製品リリースによって異なる場合があります。変更を加える前に、インストールされているSLESサービスパックのドキュメントを確認してください。
Fix Intel graphics screen tearing in Pardus Linux by checking X11 vs. Wayland, compositor settings, refresh rate, active Xorg driver, and TearFree only when appropriate.
SLES 15 で firewalld を設定する: ゾーンの確認、サービスまたはポートの許可、永続ルールの保存、安全なリロード、およびアクセスの検証。
SLES 15 SP7 でカーネルのライブパッチ適用を有効にし、再起動せずにサポートされている修正プログラムを適用し、有効なパッチを確認し、カーネルの再起動が必要な場合を把握します。
SUSEがサポートするセットアップユーティリティを使用してSLES 15でFIPSモードを有効にし、安全に再起動し、カーネルと暗号化ポリシーの状態を確認し、認証制限をチェックします。
公式の.debパッケージ、APT、ポリシーチェック、アップデートガイダンス、および管理対象デバイス向けの修正プログラムを使用して、Gooroom OSにGoogle Chromeを安全にインストールします。
rsyslog、TLS証明書、ピア名検証、キュー、検証、テスト機能を使用して、SLESシステムログをリモートのsyslogサーバーに安全に転送します。
YaSTを使用して、SSSD経由でSLES 15をActive Directoryに参加させます。DNSと時刻の設定、ドメインログインの構成、Kerberosの検証、SSSD、Winbind、およびrealmdの比較を行います。
Pardus Linux 上の RTL8821CE Wi-Fi の問題を解決するには、内蔵の rtw88 ドライバー、Realtek ファームウェア、rfkill、NetworkManager、および安全なフォールバックオプションを確認してください。
systemd-resolvedを使用して、Debian 12のDNS解決エラーを診断および修正します。これには、resolv.conf、NetworkManager、networkd、キャッシュ、および検証が含まれます。
Windows 11のバックアップ、ボリュームの縮小、UEFI USBからの起動、既存のEFIパーティションとリカバリパーティションの保護を行うことで、Windows 11の横にPardus 25.2をインストールできます。
