序章
SELinuxチュートリアルのこの最後の部分では、SELinuxユーザーとそのアクセスを微調整する方法について説明します。 また、SELinuxエラーログとエラーメッセージの意味を理解する方法についても学びます。
注このチュートリアルに示されているコマンド、パッケージ、およびファイルは、CentOS7でテストされています。 概念は他のディストリビューションでも同じです。
このチュートリアルでは、特に明記されていない限り、rootユーザーとしてコマンドを実行します。 rootアカウントにアクセスできず、sudo権限を持つ別のアカウントを使用する場合は、コマンドの前にsudo
キーワードを付ける必要があります。
SELinuxユーザー
SELinuxユーザーは、rootアカウントを含む、通常のLinuxユーザーアカウントとは異なるエンティティです。 SELinuxユーザーは、特別なコマンドを使用して作成するものではなく、サーバーへの独自のログインアクセスもありません。 代わりに、SELinuxユーザーは、起動時にメモリにロードされるポリシーで定義され、これらのユーザーはごくわずかです。 タイプまたはドメイン名が_t
で終わり、ロールが_r
で終わるのと同様に、ユーザー名は_u
で終わります。 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ドメイン内で実行されるすべてのアプリを実行する権限を持つということです。
これを示すために、rootユーザーとしてid -Z
コマンドを実行してみましょう。
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値も表示され、詳細については、このIDを使用してsealert
コマンドを実行することをお勧めします。 次のコマンドはこれを示しています(独自のアラート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の役割を果たします)。rootユーザーのウィンドウからseinfo
コマンドを使用してアクセスを確認できます。
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つのファイルに記録します。
/var/log/audit/audit.log
ファイルは、auditdデーモンが実行されている場合に使用されます。 /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
ツールはすでに見てきました。 このコマンドは、/var/log/messages
ファイルに記録されたエラーメッセージのid値で使用できます。
次のコードスニペットでは、SELinux関連のエラーの/var/log/message
ファイルを再度grep
します。
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
提案されているように、ID値を使用してsealert
を実行し、詳細を確認できました(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対応システムがポリシータイプ(/etc/selinux/config
ファイルで設定)にMLSを使用する場合、特定のファイルとプロセスを特定のレベルの感度でマークできます。 最も低いレベルは「電流感度」と呼ばれ、最も高いレベルは「クリアランス感度」と呼ばれます。
感度と密接に関連しているのは、リソースのカテゴリであり、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アカウントにマップされた新しいユーザーを作成したり、非標準のファイルの場所に適切なコンテキストを適用したりするなど、システムを保護するための可能な手順のリストを作成します。 エラーログを解読する方法を理解します。 さまざまなデーモンのポートを確認します。非標準のポートが使用されている場合は、それらがポリシーに正しく割り当てられていることを確認します。
それはすべて時間と練習と一緒になります。 :)