Linux での SELinux または AppArmor を使用した強制アクセス制御の実装
Linux には、SELinux と AppArmor という 2 種類の強制アクセス制御 (MAC) システムのサポートが組み込まれています。どちらのシステムも、Linux に付属するデフォルトの随意アクセス制御 (DAC) にアクセス制御の追加レイヤーを追加します。この記事では、両方のシステムの実装について詳しく説明し、実際の例とそれぞれの出力を示します。
SELinux と AppArmor を理解する
SELinux は Security-Enhanced Linux の略で、アクセス制御セキュリティ ポリシーをサポートするメカニズムを提供する Linux カーネル セキュリティ モジュールです。これは、システム内のすべてのオブジェクト (ファイル、ディレクトリ、ポートなど) にラベルを割り当て、ポリシーを使用してこれらのオブジェクト間の対話を定義する、非常に柔軟な MAC システムです。 SELinux は通常、堅牢で複雑なセキュリティ ポリシーが必要な状況で使用されます。
一方、AppArmor (Application Armor) は、パスベースであり、SELinux よりも設定と管理がやや簡単な別の MAC システムです。プログラムがアクセスできるファイルと機能を指定する一連のルールに従ってプログラムを制限します。使いやすさとシンプルさが重要な考慮事項である場合、AppArmor は良い選択です。
SELinuxの実装
SELinux ステータスの確認-まず、sestatus を実行して、システムで SELinux が有効になっていることを確認します。出力には、SELinux ステータスと現在の強制モードが表示されます。
$ sestatus
SELinux status: enabled
Current mode: enforcing
SELinux が無効になっている場合は、SELinux を有効にしてモードを「強制」に設定する必要があります。これを行うには、/etc/selinux/config ファイルを編集します。
SELinux コンテキストを理解する - SELinux では、すべてのファイル、ユーザー、プロセス、リソースには、アクセスの決定に使用されるコンテキストがあります。ファイルとその SELinux コンテキストを一覧表示するには、ls -Z を使用します。
$ ls -Z /var/www/html/index.html
-rw-r--r--. root root system_u:object_r:httpd_sys_content_t:s0 /var/www/html/index.html
上記の出力では、system_u:object_r:httpd_sys_content_t:s0 がファイルの SELinux コンテキストです。
ファイルコンテキストの変更 - 新しいディレクトリ /var/www/new_dir からファイルを提供するとします。デフォルトでは、SELinux は HTTP サーバーがこれらのファイルにアクセスできないようにします。 chcon コマンドを使用してディレクトリに正しいコンテキストを適用することで、アクセスを許可できます。
$ chcon -R -t httpd_sys_content_t /var/www/new_dir
ls -Z を使用して変更を確認します。
$ ls -Z /var/www/new_dir
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 /var/www/new_dir
AppArmorの実装
AppArmor ステータスの確認 - AppArmor がインストールされ、sudo systemctl status apparmor で実行されていることを確認します。出力には、AppArmor がアクティブ (実行中) であることが示されます。
$ sudo systemctl status apparmor
● apparmor.service - Load AppArmor profiles
Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor preset: enabled)
Active: active (exited) since Mon 2023-06-27 12:34:56 UTC; 1h 10min ago
AppArmor が実行されていない場合は、sudo systemctl start apparmor を使用して起動します。
AppArmor プロファイル - AppArmor は、/etc/apparmor.d/ にあるプロファイルを通じてプログラム アクセスを制御します。 sudo aa-status を使用してプロファイルを一覧表示します。
$ sudo aa-status
apparmor module is loaded.
14 profiles are loaded.
14 profiles are in enforce mode.
プロファイルの作成と適用: /usr/sbin/nginx プログラムのプロファイルを作成するとします。まず、aa-complain を使用して、このプログラムに対して AppArmor を「complain」モードにします。
$ sudo aa-complain /usr/sbin/nginx
次に、aa-genprof を使用して、プログラムの実行中にプロファイルを生成します。
$ sudo aa-genprof /usr/sbin/nginx
最後に、aa-enforce を使用してプログラムを「enforce」モードにします。
$ sudo aa-enforce /usr/sbin/nginx
これで、Nginx は指定された AppArmor プロファイルで実行され、違反は防止され、ログに記録されます。
基本的な SELinux 実装を超えて
前のセクションでは、SELinux を開始するための基本的な手順を概説しましたが、SELinux はより詳細なアクセス制御とセキュリティ機能を提供できます。
ブール値 - SELinux のブール値は、特定の機能へのアクセスを有効または無効にします。たとえば、Apache HTTP Server が任意の宛先にネットワーク接続できるようにしたいとします。これは、httpd_can_network_connect ブール値を設定することで実行できます。
$ setsebool -P httpd_can_network_connect on
このブール値の現在のステータスを表示するには、getsebool を使用します。
$ getsebool httpd_can_network_connect
httpd_can_network_connect --> on
ユーザーの役割とレベル-SELinux では、ユーザーは役割に関連付けられ、役割はドメインに関連付けられます。ユーザーに特定のロールを割り当てることで、ユーザーがアクセスできるリソースを定義できます。さらに、SELinux はマルチレベルのセキュリティをサポートしています。つまり、ユーザーとリソースの両方にセキュリティ レベルを指定して、特定のレベルのユーザーのみが同じレベルのリソースにアクセスできるようにするポリシーを作成できます。
高度な AppArmor の実装
SELinuxと同様に、AppArmorは基本機能を超える追加機能も提供します-
サブプロファイルと子プロファイル - AppArmor を使用すると、サブプロファイルと子プロファイルを作成して、アプリケーションのアクセス許可をさらに細かく制御できます。たとえば、Web サーバーの親プロファイルがある場合、そのサーバーによって実行される CGI スクリプトの子プロファイルを作成して、それらのスクリプトの権限を制限できます。
ネットワーク アクセス コントロール - AppArmor は、アプリケーションがアクセスできるネットワーク リソースを制御できます。たとえば、プログラムが特定の IP アドレスまたはポートに対してのみネットワーク接続を開くことを許可するプロファイルを作成できます。
プロファイルのスタッキング - AppArmor はプロファイルのスタッキングをサポートしています。これは、複数のプロファイルを 1 つのタスクに適用できることを意味します。これにより、さまざまなプロファイルのルールを組み合わせて、アクセス コントロール ポリシーのカスタマイズ性と粒度を高めることができます。
SELinux と AppArmor はどちらも、Linux に強制アクセス制御を実装するための強力なツールです。これらを効果的に使用する鍵は、特定のニーズと、アクセス制御ポリシーで管理したい複雑さのレベルを理解することにあります。各ツールのさまざまな機能を検討することで、状況に最も適し、システムに最大限の保護を提供するツールを選択できます。
結論
SELinux と AppArmor はどちらも堅牢なアクセス制御メカニズムを提供しますが、どちらを選択するかは特定のニーズによって異なります。システムのあらゆる側面を非常に柔軟かつきめ細かく制御する必要がある場合は、SELinux が最良の選択です。ただし、よりシンプルでユーザーフレンドリーなセキュリティアプローチを好む場合は、AppArmor の方が適しています。システムの保護は 1 回限りのアクションではなく、アクセス コントロール ポリシーの監視、更新、強制の継続的なプロセスであることに注意してください。