CentOS7でのSELinuxの概要–パート3：ユーザー

投稿日: 2019-11-08 2022-10-14
タグ: CentOS, Security, System Tools

序章

SELinuxチュートリアルのこの最後の部分では、SELinuxユーザーとそのアクセスを微調整する方法について説明します。また、SELinuxエラーログとエラーメッセージの意味を理解する方法についても学びます。

注このチュートリアルに示されているコマンド、パッケージ、およびファイルは、CentOS7でテストされています。概念は他のディストリビューションでも同じです。

このチュートリアルでは、特に明記されていない限り、rootユーザーとしてコマンドを実行します。 rootアカウントにアクセスできず、sudo権限を持つ別のアカウントを使用する場合は、コマンドの前に sudo キーワード。

SELinuxユーザー

SELinuxユーザーは、rootアカウントを含む、通常のLinuxユーザーアカウントとは異なるエンティティです。 SELinuxユーザーは、特別なコマンドを使用して作成するものではなく、サーバーへの独自のログインアクセスもありません。代わりに、SELinuxユーザーは、起動時にメモリにロードされるポリシーで定義され、これらのユーザーはごくわずかです。ユーザー名はで終わります _u、タイプやドメイン名がで終わるのと同じように _t と役割はで終わります _r. SELinuxユーザーが異なれば、システム内での権限も異なります。そのため、SELinuxユーザーは便利です。

ファイルのセキュリティコンテキストの最初の部分にリストされているSELinuxユーザーは、そのファイルを所有しているユーザーです。これは、通常のファイルの所有者に表示されるのと同じです。 ls -l コマンド出力。プロセスコンテキストのユーザーラベルは、プロセスが実行されているSELinuxユーザーの特権を示します。

SELinuxが適用されると、通常の各LinuxユーザーアカウントがSELinuxユーザーアカウントにマップされます。同じSELinuxユーザーにマップされた複数のユーザーアカウントが存在する可能性があります。このマッピングにより、通常のアカウントは対応するSELinuxのアクセス許可を継承できます。

このマッピングを表示するには、 semanage login -l 指図：

semanage login -l

CentOS 7では、これが表示される可能性があります。

Login Name           SELinux User         MLS/MCS Range        Service

__default__          unconfined_u         s0-s0:c0.c1023       *
root                 unconfined_u         s0-s0:c0.c1023       *
system_u             system_u             s0-s0:c0.c1023       *

この表の最初の列「ログイン名」は、ローカルのLinuxユーザーアカウントを表しています。ただし、ここにリストされているのは3つだけです。このチュートリアルの後半では、いくつかのアカウントを作成しませんでしたか？はい。defaultとして表示されるエントリで表されます。通常のLinuxユーザーアカウントは、最初にdefaultログインにマップされます。次に、これはunconfined_uと呼ばれるSELinuxユーザーにマップされます。この場合、これは最初の行の2番目の列です。 3番目の列は、ユーザーのマルチレベルセキュリティ/マルチカテゴリセキュリティ（MLS / MCS）クラスを示しています。今のところ、その部分とその後の列（サービス）は無視しましょう。

次に、rootユーザーがいます。「default」ログインにマップされておらず、独自のエントリが与えられていることに注意してください。この場合も、rootはunconfined_uSELinuxユーザーにマップされます。

system_uは別のクラスのユーザーであり、プロセスまたはデーモンを実行するためのものです。

システムで利用可能なSELinuxユーザーを確認するには、 semanage user 指図：

semanage user -l

CentOS7システムの出力は次のようになります。

                 Labeling   MLS/       MLS/
SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles

guest_u         user       s0         s0                             guest_r
root            user       s0         s0-s0:c0.c1023                 staff_r sysadm_r system_r unconfined_r
staff_u         user       s0         s0-s0:c0.c1023                 staff_r sysadm_r system_r unconfined_r
sysadm_u        user       s0         s0-s0:c0.c1023                 sysadm_r
system_u        user       s0         s0-s0:c0.c1023                 system_r unconfined_r
unconfined_u    user       s0         s0-s0:c0.c1023                 system_r unconfined_r
user_u          user       s0         s0                             user_r
xguest_u        user       s0         s0                             xguest_r

この大きなテーブルはどういう意味ですか？まず、ポリシーで定義されているさまざまなSELinuxユーザーが表示されます。以前はunconfined_uやsystem_uのようなユーザーを見てきましたが、今ではguest_u、staff_u、sysadm_u、user_uなどの他のタイプのユーザーも見ています。名前は、それらに関連付けられている権利をいくらか示しています。たとえば、sysadm_uユーザーはguest_uよりも多くのアクセス権を持っていると想定できます。

ゲストを確認するために、5番目の列であるSELinuxの役割を見てみましょう。このチュートリアルの最初の部分を思い出すと、SELinuxの役割はユーザーとプロセスの間のゲートウェイのようなものです。また、それらをフィルターと比較しました。ユーザーは、役割が許可する場合、役割を入力できます。ロールがプロセスドメインへのアクセスを許可されている場合、そのロールに関連付けられているユーザーはそのプロセスドメインに入ることができます。

この表から、 unconfined_u ユーザーはにマップされます system_r と unconfined_r 役割。ここでは明らかではありませんが、SELinuxポリシーでは、実際にはこれらのロールが unconfined_t ドメイン。同様に、ユーザー sysadm_u はsysadm_rロールに対して許可されていますが、guest_uはguest_rロールにマップされています。これらの各役割には、許可された異なるドメインがあります。

ここで一歩下がると、最初のコードスニペットから、rootユーザーがunconfined_uユーザーにマップするのと同じように、defaultログインがunconfined_uユーザーにマップすることもわかりました。 default ログインは通常のLinuxユーザーアカウントを表すため、これらのアカウントはsystem_rおよびunconfined_rロールに対しても承認されます。

つまり、これが実際に意味するのは、unconfined_uユーザーにマップするすべてのLinuxユーザーが、unconfined_tドメイン内で実行されるすべてのアプリを実行する権限を持つということです。

これを実証するために、を実行してみましょう id -Z rootユーザーとしてのコマンド：

id -Z

これは、rootのSELinuxセキュリティコンテキストを示しています。

unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

したがって、rootアカウントはunconfined_u SELinuxユーザーにマップされ、unconfined_uはunconfined_rロールに対して許可され、unconfined_rロールはunconfined_tドメインでプロセスを実行することを許可されます。

時間をかけて、別々のターミナルウィンドウから作成した4人のユーザーとの4つの新しいSSHセッションを開始することをお勧めします。これは、必要に応じて異なるアカウントを切り替えるのに役立ちます。

通常のユーザー
Switcheduser
ゲストユーザー
制限付きユーザー

次に、通常のユーザーとしてログインしているターミナルセッションに切り替えます。覚えているかと思いますが、 2番目のチュートリアルで多数のユーザーアカウントを作成しましたが、regularuserもその1つでした。まだ行っていない場合は、別のターミナルウィンドウを開いて、通常のユーザーとしてCentOS7システムに接続します。同じことを実行すると id -Z そこからコマンドを実行すると、出力は次のようになります。

[regularuser@localhost ~]$ id -Z

unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

この場合、regulauserアカウントはunconfined_u SELinuxユーザーアカウントにマップされ、unconfined_rロールを引き受けることができます。ロールは、制限されていないドメインでプロセスを実行できます。これは、rootアカウントもマップするSELinuxユーザー/ロール/ドメインと同じです。これは、SELinuxを対象としたポリシーにより、ログインしているユーザーが制限のないドメインで実行できるためです。

以前、SELinuxユーザーのリストを見たことがあります。

guest_u ：このユーザーはX-Windowシステム（GUI）またはネットワーキングにアクセスできず、su/sudoコマンドを実行できません。
xguest_u ：このユーザーはGUIツールにアクセスでき、Firefoxブラウザーを介してネットワークを利用できます。
user_u ：このユーザーはゲストアカウント（GUIおよびネットワーキング）よりも多くのアクセス権を持っていますが、suまたはsudoを実行してユーザーを切り替えることはできません。
staff_u ：user_uと同じ権限ですが、sudoコマンドを実行してroot権限を持つことができる点が異なります。
system_u ：このユーザーは、システムサービスを実行するためのものであり、通常のユーザーアカウントにマップされるものではありません。

SELinuxの動作1：スイッチドユーザーアクセスの制限

SELinuxがユーザーアカウントのセキュリティをどのように実施できるかを確認するために、通常のユーザーアカウントについて考えてみましょう。システム管理者は、ユーザーがrootアカウントと同じ無制限の SELinux特権を持っていることを知っており、それを変更したいと考えています。具体的には、rootアカウントを含む他のアカウントにユーザーが切り替えられるようにしたくありません。

まず、ユーザーが別のアカウントに切り替えることができるかどうかを確認しましょう。次のコードスニペットでは、regularuserがswitcheduserアカウントに切り替えています。彼はswitcheduserのパスワードを知っていると仮定します。

[regularuser@localhost ~]$ su - switcheduser
Password:
[switcheduser@localhost ~]$

次に、 root ユーザーとしてログインしているターミナルウィンドウに戻り、regularuserのSELinuxユーザーマッピングを変更します。 regularuserをuser_uにマップします。

semanage login -a -s user_u regularuser

では、ここで何をしているのでしょうか。 SELinux（-s）ユーザーアカウントuser_uに（-a）通常のユーザーアカウントを追加します。通常のユーザーがログアウトして再度ログインするまで、変更は有効になりません。

通常のユーザーのターミナルウィンドウに戻り、最初にswitcheduserから切り替えます。

[switcheduser@localhost ~]$ logout

次に、通常のユーザーもログアウトします。

[regularuser@localhost ~]$ logout

次に、新しいターミナルウィンドウを開いて、通常のユーザーとして接続します。次に、switcheduserに再度変更してみます。

[regularuser@localhost ~]$ su - switcheduser

Password:

これが私たちが今見ているものです：

su: Authentication failure

今実行すると id -Z もう一度コマンドを実行して、regularuserのSELinuxコンテキストを確認すると、出力が以前とはまったく異なることがわかります。regularuserがuser_uにマップされるようになりました。

[regularuser@localhost ~]$ id -Z

user_u:user_r:user_t:s0

では、そのような制限をどこで使用しますか？ IT組織内のアプリケーション開発チームについて考えることができます。そのチームには、会社の最新のアプリをコーディングおよびテストする開発者やテスターが多数いる場合があります。システム管理者は、開発者が自分のアカウントから一部の特権の高いアカウントに切り替えて、サーバーにアドホックな変更を加えることを知っています。アカウントを切り替える機能を制限することで、これを防ぐことができます。（ただし、それでも、特権の高いユーザーとして直接ログインすることはできます）。

SELinuxの動作2：スクリプトを実行するためのアクセス許可の制限

SELinuxを介してユーザーアクセスを制限する別の例を見てみましょう。 rootセッションからこれらのコマンドを実行します。

デフォルトでは、SELinuxでは、guest_tアカウントにマップされたユーザーがホームディレクトリからスクリプトを実行できます。実行できます getsebool ブール値をチェックするコマンド：

getsebool allow_guest_exec_content

出力は、フラグがオンになっていることを示しています。

guest_exec_content --> on

その効果を確認するために、最初に、このチュートリアルの最初に作成したguestuserアカウントのSELinuxユーザーマッピングを変更しましょう。 rootユーザーとして行います。

semanage login -a -s guest_u guestuser

を実行することでアクションを確認できます semanage login -l もう一度コマンド：

semanage login -l

ご覧のとおり、guestuserはguest_uSELinuxユーザーアカウントにマップされています。

Login Name           SELinux User         MLS/MCS Range        Service

__default__          unconfined_u         s0-s0:c0.c1023       *
guestuser            guest_u              s0                   *
regularuser          user_u               s0                   *
root                 unconfined_u         s0-s0:c0.c1023       *
system_u             system_u             s0-s0:c0.c1023       *

ゲストユーザーとしてターミナルウィンドウを開いている場合は、そこからログアウトし、ゲストユーザーとして新しいターミナルウィンドウに再度ログインします。

次に、ユーザーのホームディレクトリに非常に単純なbashスクリプトを作成します。次のコードブロックは、最初にホームディレクトリをチェックし、次にファイルを作成してコンソールで読み取ります。最後に、実行権限が変更されます。

にいることを確認します guestuser ホームディレクトリ：

[guestuser@localhost ~]$ pwd

/home/guestuser

スクリプトを作成します。

[guestuser@localhost ~]$ vi myscript.sh

スクリプトの内容：

#!/bin/bash
echo "This is a test script"

スクリプトを実行可能にします。

chmod u+x myscript.sh

ゲストユーザーとしてスクリプトを実行しようとすると、期待どおりに機能します。

[guestuser@localhost ~]$ ~/myscript.sh

This is a test script

次に、ルートターミナルウィンドウに戻り、ブール設定allow_guest_exec_contentを次のように変更します。 off そしてそれを確認します：

setsebool allow_guest_exec_content off
getsebool allow_guest_exec_content

guest\_exec\_content --> off

guestuserとしてログインしたコンソールに戻り、スクリプトを再実行しようとします。今回は、アクセスが拒否されました。

[guestuser@localhost ~]$ ~/myscript.sh

-bash: /home/guestuser/myscript.sh: Permission denied

つまり、これがSELinuxがDACの上にセキュリティの追加レイヤーを適用する方法です。ユーザーが自分のホームディレクトリに作成されたスクリプトへの完全な読み取り、書き込み、実行アクセス権を持っている場合でも、実行を停止することができます。どこで必要ですか？さて、生産システムについて考えてみてください。あなたは、あなたの会社で働いている請負業者の何人かがそうであるように、開発者がそれにアクセスできることを知っています。エラーメッセージやログファイルを表示するためにサーバーにアクセスする必要がありますが、シェルスクリプトを実行することは望ましくありません。これを行うには、最初にSELinuxを有効にしてから、対応するブール値が設定されていることを確認します。

SELinuxエラーメッセージについてはすぐに説明しますが、今のところ、この拒否がログに記録された場所を確認したい場合は、 /var/log/messages ファイル。ルートセッションからこれを実行します。

grep "SELinux is preventing" /var/log/messages

CentOS 7サーバーのファイルの最後の2つのメッセージは、アクセス拒否を示しています。

Aug 23 12:59:42 localhost setroubleshoot: SELinux is preventing /usr/bin/bash from execute access on the file . For complete SELinux messages. run sealert -l 8343a9d2-ca9d-49db-9281-3bb03a76b71a
Aug 23 12:59:42 localhost python: SELinux is preventing /usr/bin/bash from execute access on the file .

メッセージには長いID値も表示され、 sealert 詳細については、このIDを使用したコマンドを参照してください。次のコマンドはこれを示しています（独自のアラートIDを使用してください）。

sealert -l 8343a9d2-ca9d-49db-9281-3bb03a76b71a

実際、出力にはエラーに関する詳細が示されています。

SELinux is preventing /usr/bin/bash from execute access on the file .

*****  Plugin catchall_boolean (89.3 confidence) suggests   ******************

If you want to allow guest to exec content
Then you must tell SELinux about this by enabling the 'guest\_exec\_content' boolean.
You can read 'None' man page for more details.
Do
setsebool -P guest\_exec\_content 1

*****  Plugin catchall (11.6 confidence) suggests   **************************

...

大量の出力ですが、最初の数行に注意してください。

SELinuxは、/ usr / bin/bashがファイルへのアクセスを実行できないようにしています。

これにより、エラーがどこから発生しているのかがわかります。

次の数行は、エラーを修正する方法も示しています。

If you want to allow guest to exec content
Then you must tell SELinux about this by enabling the 'guest\_exec\_content' boolean.
...
setsebool -P guest\_exec\_content 1

SELinuxの動作3：サービスへのアクセスを制限する

このシリーズの最初のパートでは、ユーザー、ロール、ドメイン、およびタイプの基本的な用語を紹介するときに、SELinuxのロールについて説明しました。ここで、ユーザーアクセスの制限においてロールがどのように役割を果たすかを見てみましょう。前に述べたように、SELinuxでの役割は、ユーザーとプロセスドメインの間に位置し、ユーザーのプロセスが入ることができるドメインを制御します。ファイルセキュリティのコンテキストでロールを見ると、ロールはそれほど重要ではありません。ファイルの場合、object_rの総称値でリストされます。ユーザーやプロセスを扱うときは、役割が重要になります。

まず、httpdデーモンがシステムで実行されていないことを確認しましょう。 rootユーザーとして、次のコマンドを実行して、プロセスが停止していることを確認できます。

service httpd stop

次に、restricteduserとしてログインしたターミナルウィンドウに切り替えて、SELinuxセキュリティコンテキストを確認します。ターミナルウィンドウを開いていない場合は、システムに対して新しいターミナルセッションを開始し、このチュートリアルの最初に作成した制限付きユーザーアカウントとしてログインします。

[restricteduser@localhost ~]$ id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

したがって、アカウントには、unconfined_uユーザーとして実行され、unconfined_rロールにアクセスできるというデフォルトの動作があります。ただし、このアカウントには、システム内でプロセスを開始する権利はありません。次のコードブロックは、restricteduserがhttpdデーモンを起動しようとして、アクセス拒否エラーが発生したことを示しています。

[restricteduser@localhost ~]$ service httpd start
Redirecting to /bin/systemctl start  httpd.service
Failed to issue method call: Access denied

次に、rootユーザーのターミナルウィンドウに戻り、restricteduserアカウントが/ etc/sudoersファイルに追加されていることを確認します。このアクションにより、restricteduserアカウントがroot権限を使用できるようになります。

visudo

次に、ファイルに次の行を追加し、保存して終了します。

restricteduser ALL=(ALL)      ALL

ここでrestricteduserターミナルウィンドウからログアウトして再度ログインすると、sudo権限でhttpdサービスを開始および停止できます。

[restricteduser@localhost ~]$ sudo service httpd start


We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

[sudo] password for restricteduser:
Redirecting to /bin/systemctl start  httpd.service

ユーザーは今すぐサービスを停止することもできます：

[restricteduser@localhost ~]$ sudo service httpd stop

Redirecting to /bin/systemctl stop  httpd.service

これはすべてごく普通のことです。システム管理者は、信頼できるユーザーアカウントへのsudoアクセスを許可します。しかし、ユーザーのアカウントがsudoersファイルにリストされている場合でも、この特定のユーザーがhttpdサービスを開始しないようにするにはどうすればよいでしょうか。

これを実現する方法を確認するために、rootユーザーのターミナルウィンドウに戻って、restricteduserをSELinuxuser_rアカウントにマップしてみましょう。これは、別の例で通常のユーザーアカウントに対して行ったことです。

semanage login -a -s user_u restricteduser

制限付きユーザーのターミナルウィンドウに戻り、ログアウトして、新しい端末セッションで制限付きユーザーとして再度ログインします。

これで、restricteduserがuser_uに制限されました（つまり、user_rとdomain user_tの役割を果たします）。 seinfo rootユーザーのウィンドウからのコマンド：

seinfo -uuser_u -x

出力には、user_uが引き受けることができる役割が表示されます。これらはobject_rとuser_rです。

   user_u
      default level: s0
      range: s0
      roles:
         object_r
         user_r

さらに一歩進んで、実行することができます seinfo user_rロールが入力を許可されているドメインを確認するコマンド：

seinfo -ruser_r -x

user_rが入力を許可されているドメインはいくつかあります。

   user_r
      Dominated Roles:
         user_r
      Types:
         git_session_t
         sandbox_x_client_t
         git_user_content_t
         virt_content_t
         policykit_grant_t
         httpd_user_htaccess_t
         telepathy_mission_control_home_t
         qmail_inject_t
         gnome_home_t
		 ...
		 ...

しかし、このリストはhttpd_tをドメインの1つとして示していますか？フィルタを使用して同じコマンドを試してみましょう。

seinfo -ruser_r -x | grep httpd

ロールがアクセスできるhttpd関連のドメインは多数ありますが、httpd_tはそれらの1つではありません。

         httpd_user_htaccess_t
         httpd_user_script_exec_t
         httpd_user_ra_content_t
         httpd_user_rw_content_t
         httpd_user_script_t
         httpd_user_content_t

この例では、restricteduserアカウントがhttpdデーモンを開始しようとすると、httpdプロセスがhttpd_tドメイン内で実行され、user_rロールがアクセスを許可されているドメインの1つではないため、アクセスを拒否する必要があります。また、user_u（restricteduserにマップされている）がuser_rの役割を引き受けることができることもわかっています。制限付きユーザーアカウントにsudo特権が付与されている場合でも、これは失敗するはずです。

制限付きユーザーアカウントのターミナルウィンドウに戻って、今すぐhttpdデーモンを起動しようとします（アカウントにsudo権限が付与されていたため、以前は停止できました）。

[restricteduser@localhost ~]$ sudo service httpd start

アクセスが拒否されました：

sudo: PERM_SUDOERS: setresuid(-1, 1, -1): Operation not permitted

したがって、SELinuxがゲートキーパーのように機能する方法の別の例があります。

SELinux監査ログ

システム管理者は、SELinuxによってログに記録されたエラーメッセージを確認することに関心があります。これらのメッセージは特定のファイルに記録され、アクセス拒否に関する詳細情報を提供できます。 CentOS 7システムでは、次の2つのファイルを確認できます。

/var/log/audit/audit.log
/var/log/messages

これらのファイルには、auditdデーモンとrsyslogdデーモンがそれぞれ入力されます。では、これらのデーモンは何をするのでしょうか？マニュアルページによると、auditdデーモンはLinux監査システムのユーザースペースコンポーネントであり、rsyslogdはメッセージロギングのサポートを提供するシステムユーティリティです。簡単に言うと、これらのデーモンはエラーメッセージをこれらの2つのファイルに記録します。

The /var/log/audit/audit.log auditdデーモンが実行されている場合はファイルが使用されます。 The /var/log/messages ファイルは、auditdが停止し、rsyslogdが実行されている場合に使用されます。両方のデーモンが実行されている場合は、両方のファイルが使用されます。 /var/log/audit/audit.log 読みやすいバージョンを保持しながら、詳細情報を記録します /var/log/messages.

SELinuxエラーメッセージの解読

前のセクションで1つのSELinuxエラーメッセージを見ました（「アクション2のSELinux：スクリプトを実行するためのアクセス許可の制限」を参照）。その後、 grep ふるいにかけるコマンド /var/log/messages ファイル。幸い、SELinuxには、それよりも少し楽になるツールがいくつか付属しています。これらのツールはデフォルトではインストールされないため、このチュートリアルの最初の部分でインストールする必要があるいくつかのパッケージをインストールする必要があります。

最初のコマンドは ausearch. auditdデーモンが実行されている場合は、このコマンドを使用できます。次のコードスニペットでは、httpdデーモンに関連するすべてのエラーメッセージを確認しようとしています。 rootアカウントにいることを確認してください。

ausearch -m avc -c httpd

私たちのシステムでは、いくつかのエントリがリストされていますが、最後のエントリに集中します。

----
time->Thu Aug 21 16:42:17 2014
...
type=AVC msg=audit(1408603337.115:914): avc:  denied  { getattr } for  pid=10204 comm="httpd" path="/www/html/index.html" dev="dm-0" ino=8445484 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:default_t:s0 tclass=file

経験豊富なシステム管理者でさえ、探しているものがわからない限り、このようなメッセージに混乱する可能性があります。それを理解するために、各フィールドを分解してみましょう。

type = AVCおよびavc：AVCは Access VectorCacheの略です。 SELinuxは、リソースとプロセスのアクセス制御の決定をキャッシュします。このキャッシュは、Access Vector Cache（AVC）と呼ばれます。そのため、SELinuxアクセス拒否メッセージは「AVC拒否」とも呼ばれます。これらの2つの情報フィールドは、エントリがAVCログからのものであり、AVCイベントであることを示しています。
拒否されました{getattr}：試行されたアクセス許可と取得した結果。この場合、属性の取得操作は拒否されました。
pid=10204。これは、アクセスを試みたプロセスのプロセスIDです。
comm：プロセスID自体はあまり意味がありません。 comm属性は、プロセスコマンドを示します。この場合はhttpdです。すぐに、エラーがWebサーバーから発生していることがわかります。
path：アクセスされたリソースの場所。この場合、それは/www/html/index.htmlの下のファイルです。
devおよびino：ターゲットリソースが存在するデバイスとそのiノードアドレス。
scontext：プロセスのセキュリティコンテキスト。ソースがhttpd_tドメインで実行されていることがわかります。
tcontext：ターゲットリソースのセキュリティコンテキスト。この場合、ファイルタイプはdefault_tです。
tclass：ターゲットリソースのクラス。この場合、それはファイルです。

よく見ると、プロセスドメインはhttpd_tであり、ファイルのタイプコンテキストはdefault_tです。 httpdデーモンは制限されたドメイン内で実行され、SELinuxポリシーでは、このドメインはdefault_tタイプのファイルにアクセスできないと規定されているため、アクセスは拒否されました。

私たちはすでに見ました sealert 道具。このコマンドは、ログに記録されたエラーメッセージのid値で使用できます。 /var/log/messages ファイル。

次のコードスニペットでは、 grep を通して /var/log/message SELinux関連のエラーのファイル：

cat /var/log/messages | grep "SELinux is preventing"

私たちのシステムでは、最後のエラーを調べます。これは、restricteduserがhttpdデーモンを実行しようとしたときにログに記録されたエラーです。

...
Aug 25 11:59:46 localhost setroubleshoot: SELinux is preventing /usr/bin/su from using the setuid capability. For complete SELinux messages. run sealert -l e9e6c6d8-f217-414c-a14e-4bccb70cfbce

提案されたように、私たちは走った sealert ID値を使用して、詳細を確認できました（ID値はシステムに固有である必要があります）。

sealert -l e9e6c6d8-f217-414c-a14e-4bccb70cfbce

SELinux is preventing /usr/bin/su from using the setuid capability.

...

Raw Audit Messages
type=AVC msg=audit(1408931985.387:850): avc:  denied  { setuid } for  pid=5855 comm="sudo" capability=7  scontext=user_u:user_r:user_t:s0 tcontext=user_u:user_r:user_t:s0 tclass=capability


type=SYSCALL msg=audit(1408931985.387:850): arch=x86_64 syscall=setresuid success=no exit=EPERM a0=ffffffff a1=1 a2=ffffffff a3=7fae591b92e0 items=0 ppid=5739 pid=5855 auid=1008 uid=0 gid=1008 euid=0 suid=0 fsuid=0 egid=0 sgid=1008 fsgid=0 tty=pts2 ses=22 comm=sudo exe=/usr/bin/sudo subj=user_u:user_r:user_t:s0 key=(null)

Hash: su,user_t,user_t,capability,setuid

の出力の最初の数行がどのように sealert 修復手順について教えてください。ただし、出力ストリームの終わり近くを見ると、「未加工の監査メッセージ」セクションが表示されます。ここのエントリはから来ています audit.log 以前に説明したファイルなので、このセクションを使用して、ここで出力を解釈するのに役立てることができます。

マルチレベルセキュリティ

マルチレベルセキュリティまたはMLSは、SELinuxセキュリティコンテキストのきめ細かい部分です。

これまで、プロセス、ユーザー、またはリソースのセキュリティコンテキストに関する説明では、SELinuxユーザー、SELinuxロール、およびSELinuxタイプまたはドメインの3つの属性について説明してきました。セキュリティコンテキストの4番目のフィールドは、リソースの感度と、オプションでカテゴリを示します。

それを理解するために、FTPデーモンの構成ファイルのセキュリティコンテキストを考えてみましょう。

ls -Z /etc/vsftpd/vsftpd.conf

セキュリティコンテキストの4番目のフィールドは、s0の感度を示しています。

-rw-------. root root system_u:object_r:etc_t:s0       /etc/vsftpd/vsftpd.conf

感度は、階層マルチレベルセキュリティメカニズムの一部です。階層とは、ファイルシステム内のより安全なコンテンツのために、感度のレベルがどんどん深くなる可能性があることを意味します。レベル0（s0で示される）は、「パブリック」と言うのに匹敵する最低の感度レベルです。 sの値が高い他の感度レベルが存在する可能性があります。たとえば、内部、機密、または規制は、それぞれs1、s2、およびs3で表すことができます。このマッピングはポリシーで規定されていません。システム管理者は、各感度レベルの意味を構成できます。

SELinux対応システムがポリシータイプにMLSを使用する場合（ /etc/selinux/config file）、特定のファイルとプロセスを特定のレベルの感度でマークできます。最も低いレベルは「電流感度」と呼ばれ、最も高いレベルは「クリアランス感度」と呼ばれます。

感度と密接に関連しているのは、リソースのカテゴリであり、cで示されています。カテゴリは、リソースに割り当てられたラベルと見なすことができます。カテゴリの例としては、部門名、顧客名、プロジェクトなどがあります。分類の目的は、アクセス制御をさらに微調整することです。たとえば、2つの異なる内部部門のユーザーに対して、機密性の高い特定のファイルにマークを付けることができます。

SELinuxセキュリティコンテキストの場合、カテゴリが実装されると、感度とカテゴリが連携して機能します。ある範囲の感度レベルを使用する場合、形式はハイフンで区切られた感度レベルを表示することです（たとえば、s0-s2）。カテゴリを使用する場合、範囲はドットを挟んで表示されます。感度とカテゴリの値はコロン（:)で区切られます。

感度/カテゴリのペアの例を次に示します。

user_u:object_r:etc_t:s0:c0.c2

ここには感度レベルが1つだけあり、それがs0です。カテゴリレベルは、c0-c2と書くこともできます。

では、カテゴリレベルはどこに割り当てますか？から詳細を見つけましょう /etc/selinux/targeted/setrans.conf ファイル：

cat /etc/selinux/targeted/setrans.conf

#
# Multi-Category Security translation table for SELinux
#
#
# Objects can be categorized with 0-1023 categories defined by the admin.
# Objects can be in more than one category at a time.
# Categories are stored in the system as c0-c1023.  Users can use this
# table to translate the categories into a more meaningful output.
# Examples:
# s0:c0=CompanyConfidential
# s0:c1=PatientRecord
# s0:c2=Unclassified
# s0:c3=TopSecret
# s0:c1,c3=CompanyConfidentialRedHat
s0=SystemLow
s0-s0:c0.c1023=SystemLow-SystemHigh
s0:c0.c1023=SystemHigh

ここでは、感度とカテゴリの詳細については説明しません。プロセスは、その感度とカテゴリレベルがリソースの感度とカテゴリレベルよりも高い場合にのみ、リソースへの読み取りアクセスを許可されることを知っておいてください（つまり、プロセスドメインがリソースタイプを支配します）。プロセスは、感度/カテゴリレベルがリソースのレベルよりも低い場合にリソースに書き込むことができます。

結論

この3部構成のシリーズの短期間で、Linuxのセキュリティに関する幅広いトピックを取り上げようとしました。ここでシステムを見ると、カスタムディレクトリからコンテンツが提供されている単純なApacheWebサーバーがインストールされています。また、サーバーでFTPデーモンを実行しています。アクセスが制限されているユーザーが数人作成されました。作業を進めていく中で、セキュリティのニーズに応えるためにSELinuxパッケージ、ファイル、およびコマンドを使用しました。その過程で、SELinuxエラーメッセージを見て、それらを理解する方法も学びました。

書籍全体がSELinuxのトピックについて書かれており、さまざまなパッケージ、構成ファイル、コマンド、およびそれらがセキュリティに与える影響を理解するために何時間も費やすことができます。では、ここからどこへ行くのですか？

私がすることの1つは、実動システムで何もテストしないように注意することです。基本をマスターしたら、本番ボックスのテストレプリカでSELinuxを有効にして、SELinuxでのプレイを開始します。監査デーモンが実行されていることを確認し、エラーメッセージを監視します。サービスの開始を妨げる拒否を確認します。ブール設定を試してみてください。最も特権の低いSELinuxアカウントにマップされた新しいユーザーを作成したり、非標準のファイルの場所に適切なコンテキストを適用したりするなど、システムを保護するための可能な手順のリストを作成します。エラーログを解読する方法を理解します。さまざまなデーモンのポートを確認します。非標準のポートが使用されている場合は、それらがポリシーに正しく割り当てられていることを確認します。

それはすべて時間と練習と一緒になります。 🙂

getdocs

13036