ウェブサイト検索

RHCSA シリーズ: RHEL 7 の SELinux を使用した必須のアクセス制御の要点 - パート 13


このシリーズでは、標準の ugo/rwx 権限 (ユーザーとグループの管理 - パート 3) とアクセス コントロール リスト (ACL の構成) という少なくとも 2 つのアクセス コントロール方法を詳細に検討しました。ファイル システムについて – パート 7)。

第一レベルの権限とアクセス制御メカニズムとして必要ですが、 これらにはセキュリティ強化 Linux (略してSELinux とも呼ばれます) によって対処されるいくつかの制限があります。

このような制限の 1 つは、ユーザーが十分に練られていない chmod コマンドを通じてファイルまたはディレクトリをセキュリティ侵害にさらす可能性があり、その結果、アクセス権が予期せぬ伝播を引き起こす可能性があることです。その結果、そのユーザーが開始したプロセスはユーザーが所有するファイルを自由に操作できるようになり、最終的には悪意のあるソフトウェアまたは侵害されたソフトウェアがシステム全体へのルートレベルのアクセスを達成する可能性があります。

これらの制限を念頭に置いて、米国国家安全保障局 (NSA) は、柔軟な強制アクセス制御方法であるSELinuxを最初に考案し、プロセスがシステム オブジェクト (ファイル、ディレクトリ、ネットワーク ポートなど) にアクセスしたり、システム オブジェクトに対してその他の操作を実行したりする機能を最小限のアクセス許可モデルに設定します。これは必要に応じて後で変更できます。簡単に言うと、システムの各要素には、機能するために必要なアクセスのみが与えられます。

RHEL 7 では、SELinux がカーネル自体に組み込まれており、 デフォルトで強制 モードで有効になっています。この記事ではSELinuxとその操作に関する基本的な概念を簡単に説明します。

SELinux モード

SELinux は 3 つの異なる方法で動作できます。

  1. 強制: SELinux は、セキュリティ エンジンを制御する一連のガイドラインである SELinux ポリシー ルールに基づいてアクセスを拒否します。
  2. 許可的: SELinux はアクセスを拒否しませんが、強制モードで実行している場合に拒否されるアクションの拒否がログに記録されます。
  3. 無効です (一目瞭然)。

getenforce コマンドは SELinux の現在のモードを表示しますが、setenforce (1 または 0 が続く) は SELinux の現在のモードを表示します。現在のセッション中にのみモードをそれぞれ強制または許可に変更するために使用されます。

ログアウトと再起動後の永続性を実現するには、/etc/selinux/config ファイルを編集し、SELINUX 変数を強制または許可のいずれかに設定する必要があります。 または無効:

getenforce
setenforce 0
getenforce
setenforce 1
getenforce
cat /etc/selinux/config

通常、トラブルシューティングの最初の手順として、setenforce を使用して SELinux モードを切り替えます (強制的に許可と元に戻す)。特定の問題が発生しているときに SELinux が現在強制に設定されており、 それを許可に設定すると同じ問題が解消される場合は、安心して探していることができます。 SELinux 権限の問題で。

SELinux コンテキスト

SELinux コンテキストは、SELinux ユーザー、ロール、タイプ (およびオプションでレベル) に基づいて決定が行われるアクセス制御環境で構成されます。

  1. SELinux ユーザーは、通常の Linux ユーザー アカウントを SELinux ユーザー アカウントにマッピングすることで補完します。SELinux ユーザー アカウントは、許可されるロールとレベルを明示的に定義するために、そのセッション内のプロセスの SELinux コンテキストで使用されます。
  2. ロールの概念は、アクセスできるプロセス ドメインとファイル タイプを定義するという点で、ドメインと SELinux ユーザーの間の仲介者として機能します。これにより、特権昇格攻撃に対する脆弱性からシステムが保護されます。
  3. タイプは、SELinux ファイル タイプまたは SELinux プロセス ドメインを定義します。通常の状況では、プロセスは他のプロセスが使用するファイルにアクセスしたり、他のプロセスにアクセスしたりすることを禁止されているため、アクセスを許可する特定の SELinux ポリシー ルールが存在する場合にのみアクセスが許可されます。

次の例を通して、これらすべてがどのように機能するかを見てみましょう。

例 1: sshd デーモンのデフォルト ポートの変更

「SSH の保護 – パート 8」では、sshd がリッスンするデフォルト ポートの変更が、サーバーを外部攻撃から保護するための最初のセキュリティ対策の 1 つであると説明しました。 /etc/ssh/sshd_config ファイルを編集して、ポートを 9999 に設定しましょう。

Port 9999

変更を保存し、sshd を再起動します。

systemctl restart sshd
systemctl status sshd

ご覧のとおり、sshd の起動に失敗しました。しかし何が起こった?

/var/log/audit/audit.log を簡単に検査すると、sshd がポート 9999 で起動するアクセス許可が拒否されたことがわかります (SELinux ログ メッセージには「 >AVC」という名前を付けると、他のメッセージから簡単に識別できるようになります)。これはJBoss Management サービス用に予約されているポートであるためです。

cat /var/log/audit/audit.log | grep AVC | tail -1

この時点で、前に説明したように SELinux を無効にして (無効にしないでください)、sshd を再度起動してみると、機能するはずです。ただし、semanage ユーティリティは、選択したポートで問題なく sshd を起動できるようにするために何を変更する必要があるかを教えてくれます。

走る、

semanage port -l | grep ssh

SELinux が sshd のリッスンを許可するポートのリストを取得します。

そこで、/etc/ssh/sshd_config のポートをポート 9998 に変更し、そのポートを ssh_port_t コンテキストに追加して、サービスを再起動しましょう。 :

semanage port -a -t ssh_port_t -p tcp 9998
systemctl restart sshd
systemctl is-active sshd

ご覧のとおり、今回は正常にサービスが開始されました。この例は、SELinux が独自のポート タイプの内部定義に従って TCP ポート番号を制御するという事実を示しています。

例 2: httpd に sendmail へのアクセスを許可する

これは、別のプロセスにアクセスするプロセスを管理する SELinux の例です。 RHEL 7 サーバーで Apache とともに mod_security と mod_evasive を実装する場合は、httpdsendmail にアクセスできるようにして、メール通知の後にメール通知を送信する必要があります。 (D)DoS攻撃。再起動後も変更を永続的にしたくない場合は、次のコマンドで -P フラグを省略します。

semanage boolean -1 | grep httpd_can_sendmail
setsebool -P httpd_can_sendmail 1
semanage boolean -1 | grep httpd_can_sendmail

上記の例からわかるように、SELinux ブール値 設定 (または単にブール値) は、SELinux ポリシーに埋め込まれた true/false ルールです。 semanage boolean -l を使用してすべてのブール値をリストすることも、出力をフィルタリングするために grep にパイプすることもできます。

例 3: デフォルト以外のディレクトリから静的サイトを提供する

デフォルトのディレクトリ (/var/www/html) とは異なるディレクトリ、たとえば /websites を使用して静的 Web サイトを提供しているとします (これは、たとえば、Web ファイルを共有ネットワーク ドライブに保存し、/websites にマウントする必要があります)。

a). 次の内容を含む index.html ファイルを /websites 内に作成します。

<html>
<h2>SELinux test</h2>
</html>

もし、するなら、

ls -lZ /websites/index.html

index.html ファイルには、Apache がアクセスできない default_t SELinux タイプのラベルが付いていることがわかります。

b). /etc/httpd/conf/httpd.confDocumentRoot ディレクティブを /websites に変更します。対応するディレクトリ ブロックを更新することを忘れないでください。次に、Apache を再起動します。

c). http:// を参照すると、503 Forbidden HTTP 応答が返されます。

d). 次に、/websites のラベルを再帰的に httpd_sys_content_t タイプに変更して、Apache に読み取り専用アクセスを許可します。ディレクトリとその内容:

semanage fcontext -a -t httpd_sys_content_t "/websites(/.*)?"

e). 最後に、d) で作成した SELinux ポリシーを適用します。

restorecon -R -v /websites

ここで Apache を再起動し、再度 http:// を参照すると、HTML ファイルが正しく表示されることがわかります。

まとめ

この記事ではSELinuxの基本について説明しました。主題が膨大であるため、1 つの記事で完全に詳細に説明することは不可能ですが、このガイドで概説されている原則は、必要に応じてより高度なトピックに進むのに役立つと考えられます。

できれば、まず 2 つの重要なリソースをお勧めします。NSA SELinux ページと RHEL 7 SELinux ユーザーおよび管理者ガイドです。

ご質問やご意見がございましたら、お気軽にお知らせください。