Linux での SELinux または AppArmor を使用した強制アクセス制御の実装
標準の ugo/rwx 権限とアクセス制御リストによって提供されるセキュリティ メカニズムの制限を克服し、強化するために、米国国家安全保障局 (NSA) は柔軟な < SELinux (Security Enhanced Linux の略) として知られる強力な強制アクセス制御 (MAC) メソッド。特に、プロセスの機能を制限します。システム オブジェクト (ファイル、ディレクトリ、ネットワーク ポートなど) にアクセスしたり、システム オブジェクト (ファイル、ディレクトリ、ネットワーク ポートなど) に対してその他の操作を実行したりする際に、このモデルに対する後からの変更を可能にしながら、可能な限り最小限の権限でアクセスします。
もう 1 つの人気があり広く使用されている MAC は AppArmor です。これには、SELinux が提供する機能に加えて、システムが「学習できるようにする学習モード」が含まれています。 Strong> 」は、特定のアプリケーションがどのように動作するかを確認し、アプリケーションを安全に使用するためにプロファイルを構成することで制限を設定します。
CentOS 7 では、SELinux がカーネル自体に組み込まれており、 デフォルトで強制 モードで有効になります (これについては次のセクションで詳しく説明します)。 AppArmor を使用する openSUSE と Ubuntu とは対照的です。
この記事では、SELinux と AppArmor の基本事項と、選択したディストリビューションに応じてこれらのツールのいずれかを有益に使用する方法について説明します。
SELinux の概要と CentOS 7 での使用方法
Security Enhanced Linux は、次の 2 つの異なる方法で動作できます。
- 強制: SELinux は、セキュリティ エンジンを制御する一連のガイドラインである SELinux ポリシー ルールに基づいてアクセスを拒否します。
- 許可的: SELinux はアクセスを拒否しませんが、強制モードで実行している場合に拒否されるアクションの拒否がログに記録されます。
SELinux を無効にすることもできます。これは動作モードそのものではありませんが、それでもオプションです。ただし、このツールを無視するよりは、その使用方法を学習する方が良いでしょう。覚えておいてください！
SELinux の現在のモードを表示するには、getenforce を使用します。操作モードを切り替える場合は、setenforce 0 (Permissive に設定する場合) または setenforce 1 (Enforcing に設定する場合) を使用します。strong>)。
この変更は再起動後は反映されないため、/etc/selinux/config ファイルを編集し、SELINUX 変数を次のいずれかに設定する必要があります。再起動後の永続性を実現するには、enforcing、permissive、または disabled を選択します。
余談ですが、getenforce が Disabled を返した場合は、/etc/selinux/config を目的の動作モードで編集して再起動する必要があります。そうしないと、setenforce で動作モードを設定 (または切り替え) できなくなります。
setenforce の一般的な使用法の 1 つは、SELinux モードを切り替えることで構成されます (強制 から許可、またはその逆)。不正な動作をしているか、期待どおりに動作していません。 SELinux を許可 モードに設定した後に動作する場合は、SELinux の許可に問題があると確信できます。
SELinux に対処する必要がある可能性が最も高い 2 つの典型的なケースは次のとおりです。
- デーモンがリッスンするデフォルトのポートを変更します。
- /var/www/html の外部にある仮想ホストの DocumentRoot ディレクティブを設定します。
次の例を使用して、これら 2 つのケースを見てみましょう。
例 1: sshd デーモンのデフォルト ポートの変更
ほとんどのシステム管理者がサーバーを保護するために最初に行うことの 1 つは、SSH デーモンがリッスンするポートを変更することです。これは主にポート スキャナーや外部攻撃者を阻止するためです。これを行うには、次のように /etc/ssh/sshd_config の Port ディレクティブに続いて新しいポート番号を使用します (この場合はポート 9999 を使用します)。
Port 9999
サービスを再起動してステータスを確認すると、開始に失敗したことがわかります。
systemctl restart sshd
systemctl status sshd
/var/log/audit/audit.log を見ると、sshd がポート 9999 で起動できなくなっていることがわかります。これはJBoss Management サービス用に予約されているポートであるため、SELinux によって保存されます (SELinux ログ メッセージには、「AVC」 という単語が含まれているため、簡単に識別できます)他のメッセージから識別されます):
cat /var/log/audit/audit.log | grep AVC | tail -1
この時点で、ほとんどの人はおそらくSELinux を無効にするでしょうが、私たちは無効にしません。 SELinux と、別のポートでリッスンする sshd が調和して共存する方法があることがわかります。 policycoreutils-python パッケージがインストールされていることを確認し、実行します。
yum install policycoreutils-python
SELinux が sshd のリッスンを許可するポートのリストを表示します。次の画像では、ポート 9999 が別のサービス用に予約されているため、当面はそのポートを使用して別のサービスを実行できないこともわかります。
semanage port -l | grep ssh
もちろん、SSH 用に別のポートを選択することもできますが、JBoss 関連サービスにこの特定のマシンを使用する必要がないと確信している場合は、既存の SELinux ルールを変更して、代わりにそのポートを SSH に割り当てることができます。
semanage port -m -t ssh_port_t -p tcp 9999
その後、最初の semanage コマンドを使用して、ポートが正しく割り当てられたかどうかを確認するか、-lC オプション (list Custom の略) を使用できます。
semanage port -lC
semanage port -l | grep ssh
これで SSH を再起動し、ポート 9999 を使用してサービスに接続できるようになりました。この変更は再起動後も存続することに注意してください。
例 2: 仮想ホストとして /var/www/html の外部にある DocumentRoot を選択する
/var/www/html 以外のディレクトリを DocumentRoot として使用して Apache 仮想ホストをセットアップする必要がある場合 (たとえば、/websrv/sites) /ガブリエル/public_html):
DocumentRoot “/websrv/sites/gabriel/public_html”
index.html には Apache がアクセスできない default_t SELinux タイプのラベルが付けられているため、Apache はコンテンツの提供を拒否します。
wget http://localhost/index.html
ls -lZ /websrv/sites/gabriel/public_html/index.html
前の例と同様に、次のコマンドを使用して、これが実際に SELinux 関連の問題であることを確認できます。
cat /var/log/audit/audit.log | grep AVC | tail -1
/websrv/sites/gabriel/public_html のラベルを httpd_sys_content_t に再帰的に変更するには、次の手順を実行します。
semanage fcontext -a -t httpd_sys_content_t "/websrv/sites/gabriel/public_html(/.*)?"
上記のコマンドは、Apache にそのディレクトリとその内容への読み取り専用アクセスを許可します。
最後に、ポリシーを適用するには (そしてラベルの変更をすぐに有効にするには)、次の手順を実行します。
restorecon -R -v /websrv/sites/gabriel/public_html
これで、ディレクトリにアクセスできるようになります。
wget http://localhost/index.html
SELinux の詳細については、『Fedora 22 SELinux および管理者ガイド』を参照してください。