Loading article…
| アプリアーマー | |
|---|---|
 | |
| 原作者 | イミュニクス |
| 開発者 | 元々はImmunix社（1998年～2005年）、その後Novell傘下のSUSE社（2005年～2009年）、そして現在はCanonical Ltd社（2009年以降）が所有している。 |
| リリース | 1998年 （1998年） |
| 安定放出 | |
| 執筆 | C、Python、C++、sh [ 2 ] |
| オペレーティング·システム | Linux |
| タイプ | セキュリティ、Linuxセキュリティモジュール（LSM） |
| ライセンス | GNU一般公衆利用許諾書 |
| Webサイト | apparmor.net |
| リポジトリ | gitlab.com/apparmor |
AppArmor（「アプリケーションアーマー」）は、Linuxカーネルのセキュリティモジュールであり、システム管理者がプログラムごとのプロファイルを使用してプログラムの機能を制限できるようにします。プロファイルでは、ネットワークアクセス、生ソケットアクセス、一致するパス上のファイルの読み取り、書き込み、実行などの機能を許可できます。AppArmorは、従来のUnixの任意アクセス制御（DAC）モデルを補完し、強制アクセス制御（MAC）を提供します。バージョン2.6.36以降、Linuxカーネルのメインラインに部分的に組み込まれています。Canonical は2009年からAppArmorの開発を支援しています。
AppArmorは、プロファイルを手動で作成する機能に加え、学習モードも備えています。このモードでは、プロファイル違反はログに記録されますが、防止されるわけではありません。このログは、プログラムの典型的な動作に基づいてAppArmorプロファイルを生成するために使用できます。
AppArmorは、Linuxセキュリティモジュール（LSM）カーネルインターフェースを使用して実装されています。
AppArmor は、管理者が設定や維持管理が難しいと批判されているSELinuxの代替として提供されています。 [ 3 ]ファイルにラベルを適用することに基づく SELinux とは異なり、AppArmor はファイル パスで動作します。AppArmor の支持者は、SELinux よりも複雑ではなく、平均的なユーザーが学習しやすいと主張しています。[ 4 ]また、AppArmor は既存のシステムで動作させるために必要な変更が少ないとも主張しています。たとえば、SELinux は「セキュリティ ラベル」をサポートするファイルシステムを必要とするため、NFS経由でマウントされたファイルへのアクセス制御を提供できません。AppArmor はファイルシステムに依存しません。
AppArmor は 1998～2003 年にImmunix Linuxで初めて使用されました。当時、AppArmor は SubDomain と呼ばれていました[ 5 ] [ 6 ]。これは、特定のプログラムのセキュリティ プロファイルを異なるドメインに分割し、プログラムが動的に切り替えることができる機能を指していました。AppArmor はSLESとopenSUSEで初めて利用可能になり、SLES 10 と openSUSE 10.1 でデフォルトで有効になりました。
2005 年 5 月にNovell はImmunix を買収し、SubDomain をAppArmor にブランド変更し、 Linuxカーネルへの組み込みに向けてコードのクリーンアップと書き換えを開始しました。 [ 7 ] 2005 年から 2007 年 9 月まで、AppArmor は Novell によって保守されていました。 現在、 SUSE はAppArmor という商標名の法的所有者です。[ 8 ] openSUSE Tumbleweed は 2025 年 2 月 11 日以降、新規インストールで AppArmor から SELinux に移行し、openSUSE Leap 16 もデフォルトで SELinux に切り替わりました。[ 9 ] AppArmor は、それを好むユーザーのためにインストール時に選択できます。[ 10 ]
AppArmor は 2007 年 4 月にUbuntu向けに初めて移植/パッケージ化されました。AppArmorは Ubuntu 7.10 からデフォルト パッケージになりました。Ubuntu 8.04 では、デフォルトではCUPSのみを保護していました。Ubuntu 9.04 以降では、MySQL などの項目にプロファイルがインストールされました。Ubuntu 9.10 では、ゲスト セッション、 libvirt仮想マシン、Evince (ドキュメント ビューア)、およびオプションの Firefox プロファイルのプロファイルが追加され、AppArmor のセキュリティ強化がさらに向上しました。[ 11 ]
AppArmorは2010年10月のカーネルリリース2.6.36に統合されました。[ 12 ] [ 13 ] [ 14 ] [ 15 ]
AppArmorは2014年の5.1ベータ版以降、SynologyのDSMに統合されています。[ 16 ]
AppArmorは2017年8月15日のSolusリリース3で有効化されました。 [ 17 ]
AppArmorは、2019年7月にリリースされたDebian 10（Buster）でデフォルトで有効になっています。[ 18 ]
AppArmorは、インストールされたソフトウェアが実行できる動作を制限するという問題に対する、いくつかの可能なアプローチの1つです。
SELinuxシステムは一般的に AppArmor と同様のアプローチを採用しています。重要な違いが 1 つあります。SELinux はパスではなくinode番号でファイルシステム オブジェクトを識別します。AppArmor では、ハード リンクが作成されるとアクセスできないファイルにもアクセスできるようになります。Ubuntu 10.10 以降では Yama と呼ばれるセキュリティ モジュールでこの問題が緩和されており、このモジュールは他のディストリビューションでも使用されているため、この違いは以前ほど重要ではなくなってきています。[ 19 ] SELinux の inode ベースのモデルでは、ハード リンクがアクセスできない inode を指しているため、新しく作成されたハード リンクを介したアクセスは常に本質的に拒否されてきました。
SELinuxとAppArmorは、管理方法やシステムへの統合方法においても大きく異なります。
プロセスの分離は、仮想化などのメカニズムによっても実現できる。
2007年に、簡素化された強制アクセス制御カーネルが導入された。
2009年、Linux 2.6.30にTomoyoと呼ばれる新しいソリューションが導入されました。AppArmorと同様に、Tomoyoもパスベースのアクセス制御を使用します。
{{cite web}}: CS1メンテナンス: アーカイブサービスは非推奨になりました (リンク)