前書き
SELinuxチュートリアルのこの最後の部分では、SELinuxユーザーとそのアクセスを微調整する方法について説明します。 また、SELinuxエラーログと、エラーメッセージを理解する方法についても学習します。
_ 注意 +このチュートリアルに示されているコマンド、パッケージ、およびファイルは、CentOS 7でテストされています。 他のディストリビューションでも概念は同じです。 _
このチュートリアルでは、特に明記しない限り、rootユーザーとしてコマンドを実行します。 ルートアカウントにアクセスできず、sudo特権を持つ別のアカウントを使用する場合は、コマンドの前に「+ sudo +」キーワードを付ける必要があります。
SELinuxユーザー
SELinuxユーザーは、ルートアカウントを含む通常のLinuxユーザーアカウントとは異なるエンティティです。 SELinuxユーザーは、特別なコマンドで作成するものではなく、サーバーへの独自のログインアクセス権も持ちません。 代わりに、起動時にメモリに読み込まれるポリシーでSELinuxユーザーが定義されますが、これらのユーザーはごく少数です。 タイプまたはドメイン名が「+ _t 」で終わり、ロールが「 _r 」で終わるように、ユーザー名は「 _u +」で終わります。 SELinuxユーザーが異なれば、システムに対する権限も異なります。これが、ユーザーを便利にしている理由です。
ファイルのセキュリティコンテキストの最初の部分にリストされているSELinuxユーザーは、そのファイルを所有しているユーザーです。 これは、通常の `+ ls -l +`コマンドの出力からファイルの所有者を見かけるようなものです。 プロセスコンテキストのユーザーラベルは、プロセスが実行されているSELinuxユーザーの特権を示します。
SELinuxが適用されると、通常のLinuxユーザーアカウントはそれぞれSELinuxユーザーアカウントにマップされます。 同じSELinuxユーザーに複数のユーザーアカウントをマップできます。 このマッピングにより、通常のアカウントは、SELinuxの同等の権限を継承できます。
このマッピングを表示するには、 `+ semanage login -l +`コマンドを実行します：
semanage login -lCentOS 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つしかリストされていません。このチュートリアルの第2部でいくつかのアカウントを作成しませんでしたか？ はい。それらは default として表示されるエントリで表されます。 通常のLinuxユーザーアカウントは最初に default ログインにマッピングされます。 これは、unconfined_uというSELinuxユーザーにマップされます。 この場合、これは最初の行の2番目の列です。 3番目の列は、ユーザーのマルチレベルセキュリティ/マルチカテゴリセキュリティ（MLS / MCS）クラスを示しています。 とりあえず、その部分とその後の列（サービス）も無視しましょう。
次に、* root ユーザーがいます。 「 default *」ログインにマッピングされるのではなく、独自のエントリが与えられていることに注意してください。 ここでも、rootはunconfined_u SELinuxユーザーにマップされます。
system_uは、プロセスまたはデーモンを実行するための異なるクラスのユーザーです。
システムで使用可能なSELinuxユーザーを確認するには、 `+ semanage user +`コマンドを実行します。
semanage user -lCentOS 7システムの出力は次のようになります。
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ロールはユーザーとプロセスの間のゲートウェイのようなものです。 また、それらをフィルターと比較しました。ロールが許可する場合、ユーザーはロールを_enter_できます。 ロールがプロセスドメインへのアクセスを許可されている場合、そのロールに関連付けられているユーザーはそのプロセスドメインに入ることができます。
これで、このテーブルから、 `+ unconfined_u `ユーザーが ` system_r `および ` unconfined_r `ロールにマッピングされていることがわかります。 ここでは明らかではありませんが、SELinuxポリシーは実際にこれらのロールが ` unconfined_t `ドメインでプロセスを実行することを許可します。 同様に、ユーザー ` sysadm_u +`はsysadmrロールに対して許可されていますが、guestuはguest_rロールにマップされています。 これらの各ロールには、異なるドメインが割り当てられます。
さて、一歩後退すると、最初のコードスニペットから、rootユーザーがunconfined_uユーザーにマップするのと同様に、 default ログインがunconfineduユーザーにマップされることもわかりました。 default _