前書き

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 -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つしかリストされていません。このチュートリアルの第2部でいくつかのアカウントを作成しませんでしたか? はい。それらは default として表示されるエントリで表されます。 通常のLinuxユーザーアカウントは最初に default ログインにマッピングされます。 これは、unconfined_uというSELinuxユーザーにマップされます。 この場合、これは最初の行の2番目の列です。 3番目の列は、ユーザーのマルチレベルセキュリティ/マルチカテゴリセキュリティ(MLS / MCS)クラスを示しています。 とりあえず、その部分とその後の列(サービス)も無視しましょう。

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

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

システムで使用可能なSELinuxユーザーを確認するには、 `+ semanage user +`コマンドを実行します。

semanage user -l

CentOS 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 _ ログインは通常の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セッションを開始するために時間をかけることをお勧めします。 これにより、必要に応じて異なるアカウントを切り替えることができます。

  • 一般ユーザー

  • 切り替えユーザー

  • ゲストユーザー

  • 制限ユーザー

次に、通常ユーザーとしてログインしたターミナルセッションに切り替えます。 覚えているなら、https://www.digitalocean.com/community/tutorials/an-introduction-to-selinux-on-centos-7-part-2-files-and-processesにいくつかのユーザーアカウントを作成しました。 [2番目のチュートリアル]、regularuserもその一人です。 まだ行っていない場合は、別のターミナルウィンドウを開いて、CentOS 7システムに通常ユーザーとして接続します。 そこから同じ `+ id -Z +`コマンドを実行すると、出力は次のようになります。

[[email protected] ~]$ 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 *:sudoコマンドを実行してルート権限を取得できることを除いて、user_uと同じ権限。

  • * system_u *:このユーザーは、システムサービスを実行するためのものであり、通常のユーザーアカウントにはマッピングされません。

SELinux in Action 1:スイッチユーザーアクセスの制限

SELinuxがユーザーアカウントにセキュリティを適用する方法を確認するために、通常のユーザーアカウントについて考えてみましょう。 システム管理者は、ユーザーがrootアカウントと同じ無制限の_SELinux特権_を持っていることを知っているので、それを変更したいと思います。 具体的には、ユーザーがルートアカウントを含む他のアカウントに切り替えられないようにします。

最初に、ユーザーが別のアカウントに切り替える能力を確認しましょう。 次のコードスニペットでは、通常ユーザーがスイッチドユーザーアカウントに切り替えています。 彼がスイッチドユーザーのパスワードを知っていると仮定します。

[[email protected] ~]$ su - switcheduser
Password:
[[email protected] ~]$

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

semanage login -a -s user_u regularuser

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

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

[[email protected] ~]$ logout

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

[[email protected] ~]$ logout

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

[[email protected] ~]$ su - switcheduser
Password:

これが今見ているものです。

su: Authentication failure

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

[[email protected] ~]$ id -Z
user_u:user_r:user_t:s0

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

SELinux in Action 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_u SELinuxユーザーアカウントにマッピングされています。

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       *

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

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

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

/home/guestuser

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

[[email protected] ~]$ vi myscript.sh

スクリプトの内容:

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

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

chmod u+x myscript.sh

guestuserとしてスクリプトを実行しようとすると、期待どおりに動作します。

[[email protected] ~]$ ~/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

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

[[email protected] ~]$ ~/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

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

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 in Action 3:サービスへのアクセスを制限する

https://www.digitalocean.com/community/tutorials/an-introduction-to-selinux-on-centos-7-part-1-basic-concepts [このシリーズの最初の部分]では、SELinuxの役割について話しました。ユーザー、ロール、ドメイン、タイプの基本的な用語を紹介しました。 ここで、ユーザーアクセスの制限において役割がどのように役割を果たすかを見てみましょう。 前述したように、SELinuxの役割はユーザーとプロセスドメインの間に位置し、ユーザーのプロセスがどのドメインに入ることができるかを制御します。 ロールは、ファイルセキュリティコンテキストで見るとそれほど重要ではありません。 ファイルの場合、object_rの一般的な値でリストされます。 ユーザーとプロセスを扱う場合、役割が重要になります。

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

service httpd stop

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

[[email protected] ~]$ id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

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

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

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

visudo

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

restricteduser ALL=(ALL)      ALL

制限付きユーザー端末ウィンドウからログアウトして再度ログインすると、sudo特権でhttpdサービスを開始および停止できます。

[[email protected] ~]$ 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

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

[[email protected] ~]$ sudo service httpd stop
Redirecting to /bin/systemctl stop  httpd.service

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

これを実現する方法を確認するには、rootユーザーのターミナルウィンドウに戻り、制限付きユーザーをSELinux user_rアカウントにマッピングします。 これは、別の例で通常ユーザーアカウントに対して行ったことです。

semanage login -a -s user_u restricteduser

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

これで、restricteduserはuser_u(およびロールuser_rとドメインuser_tを意味します)に制限されたので、ルートユーザーのウィンドウから `+ 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
        ...
        ...

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

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ロールがアクセスを許可されているドメインではないため、アクセスを拒否する必要があります そして、user_u(restricteduserにマッピング)がuser_rロールを引き受けることができることを知っています。 これは、restricteduserアカウントにsudo特権が付与されている場合でも失敗するはずです。

制限されたユーザーアカウントのターミナルウィンドウに戻り、httpdデーモンを今すぐ開始しようとします(アカウントにsudo特権が付与されているため、これを停止できました)。

[[email protected] ~]$ 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つのファイルにエラーメッセージを記録します。

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

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

前のセクションで1つのSELinuxエラーメッセージを確認しました(「SELinux in Action 2:スクリプトを実行するためのアクセス許可の制限」を参照)。 次に、 + / var / log / messages`ファイルを選別するために + grep`コマンドを使用していました。 幸いなことに、SELinuxには、それよりも生活を少し楽にするいくつかのツールが付属しています。 これらのツールはデフォルトではインストールされず、このチュートリアルの最初の部分でインストールする必要があるいくつかのパッケージをインストールする必要があります。

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

ausearch -m avc -c httpd

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

時間→木8月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

Even experienced system administrators can get confused by messages like this unless they know what they are looking for. To understand it, let’s take apart each of the fields:

* type=AVC and avc: AVC stands for _Access Vector Cache_. SELinux caches access control decisions for resource and processes. This cache is known as the Access Vector Cache (AVC). That’s why SELinux access denial messages are also known as “AVC denials”. These two fields of information are saying the entry is coming from an AVC log and it’s an AVC event.
* denied \{ getattr }: The permission that was attempted and the result it got. In this case the get attribute operation was denied.
* pid=10204. This is the process id of the process that attempted the access.
* comm: The process id by itself doesn’t mean much. The comm attribute shows the process command. In this case it’s httpd. Immediately we know the error is coming from the web server.
* path: The location of the resource that was accessed. In this case it’s a file under /www/html/index.html.
* dev and ino: The device where the target resource resides and its inode address.
* scontext: The security context of the process. We can see the source is running under the httpd_t domain.
* tcontext: The security context of the target resource. In this case the file type is default_t.
* tclass: The class of the target resource. In this case it’s a file.

If you look closely, the process domain is httpd_t and the file’s type context is default_t. Since the httpd daemon runs within a confined domain and SELinux policy stipulates this domain doesn’t have any access to files with default_t type, the access was denied.

We have already seen the `+sealert+` tool. This command can be used with the id value of the error message logged in the `+/var/log/messages+` file.

In the following code snippet we again `+grep+` through the the `+/var/log/message+` file for SELinux related errors:

[source,code-pre]

cat / var / log / messages | grep「SELinuxが妨げている」

In our system, we look at the very last error. This is the error that was logged when our restricteduser tried to run the httpd daemon:

[source,code-pre]

…​
8月25日11:59:46 localhost setroubleshoot:SELinuxが/ usr / bin / suがsetuid機能を使用することを妨げています。 完全なSELinuxメッセージ用。 sealert -l e9e6c6d8-f217-414c-a14e-4bccb70cfbceを実行します

As suggested, we ran `+sealert+` with the ID value and were able to see the details (your ID value should be unique to your system):

[source,code-pre]

sealert -l

[source,code-pre]

SELinuxは、/ usr / bin / suがsetuid機能を使用することを妨げています。

…​

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 = (ヌル)

ハッシュ:su、user_t、user_t、capability、setuid

We have seen how the first few lines of the output of `+sealert+` tell us about the remediation steps. However, if we now look near the end of the output stream, we can see the “Raw Audit Messages” section. The entry here is coming from the `+audit.log+` file, which we discussed earlier, so you can use that section to help you interpret the output here.

=== Multilevel Security

Multilevel security or *MLS* is the fine-grained part of an SELinux security context.

So far in our discussion about security contexts for processes, users, or resources we have been talking about three attributes: SELinux user, SELinux role, and SELinux type or domain. The fourth field of the security context shows the _sensitivity_ and optionally, the _category_ of the resource.

To understand it, let’s consider the security context of the FTP daemon’s configuration file:

[source,code-pre]

ls -Z /etc/vsftpd/vsftpd.conf

The fourth field of the security context shows a sensitivity of s0.

[source,code-pre]

-rw ——-。 ルートルートsystem_u:object_r:etc_t:s0 /etc/vsftpd/vsftpd.conf

The sensitivity is part of the _hierarchical_ multilevel security mechanism. By hierarchy, we mean the levels of sensitivity can go deeper and deeper for more secured content in the file system. Level 0 (depicted by s0) is the lowest sensitivity level, comparable to say, “public.” There can be other sensitivity levels with higher s values: for example, internal, confidential, or regulatory can be depicted by s1, s2, and s3 respectively. This mapping is not stipulated by the policy: system administrators can configure what each sensitivity level mean.

When a SELinux enabled system uses MLS for its policy type (configured in the `+/etc/selinux/config+` file), it can mark certain files and processes with certain levels of sensitivity. The lowest level is called “current sensitivity” and the highest level is called “clearance sensitivity”.

Going hand-in-hand with sensitivity is the _category_ of the resource, depicted by c. Categories can be considered as labels assigned to a resource. Examples of categories can be department names, customer names, projects etc. The purpose of categorization is to further fine-tune access control. For example, you can mark certain files with confidential sensitivity for users from two different internal departments.

For SELinux security contexts, sensitivity and category work together when a category is implemented. When using a range of sensitivity levels, the format is to show sensitivity levels separated by a hyphen (for example, s0-s2). When using a category, a range is shown with a dot in between. Sensitivity and category values are separated by a colon (:).

Here is an example of sensitivity / category pair:

[source,code-pre]

user_u:object_r:etc_t:s0:c0.c2

There is only one sensitivity level here and that’s s0. The category level could also be written as c0-c2.

So where do you assign your category levels? Let’s find the details from the `+/etc/selinux/targeted/setrans.conf+` file:

[source,code-pre]

cat /etc/selinux/targeted/setrans.conf

[source,code-pre]

##SELinuxのマルチカテゴリセキュリティ変換テーブル###オブジェクトは、管理者が定義した0〜1023のカテゴリに分類できます。 #オブジェクトは一度に複数のカテゴリに属する​​ことができます。 #カテゴリは、c0-c1023としてシステムに保存されます。 ユーザーはこの#テーブルを使用して、カテゴリをより意味のある出力に変換できます。 #例:#s0:c0 = CompanyConfidential#s0:c1 = PatientRecord#s0:c2 = Unclassified#s0:c3 = TopSecret#s0:c1、c3 = CompanyConfidentialRedHat s0 = SystemLow s0-s0:c0.c1023 = SystemLow-SystemHighs :c0.c1023 = SystemHigh

We won’t go into the details of sensitivities and categories here. Just know that a process is allowed read access to a resource only when its sensitivity and category level is higher than that of the resource (i.e. the process domain _dominates_ the resource type). The process can write to the resource when its sensitivity/category level is less than that of the resource.

==== Conclusion

We have tried to cover a broad topic on Linux security in the short span of this three-part-series. If we look at our system now, we have a simple Apache web server installed with its content being served from a custom directory. We also have an FTP daemon running in our server. There were a few users created whose access have been restricted. As we went along, we used SELinux packages, files, and commands to cater to our security needs. Along the way we also learned how to look at SELinux error messages and make sense of them.

Entire books have been written on the SELinux topic and you can spend hours trying to figure out different packages, configuration files, commands, and their effects on security. So where do you go from here?

One thing I would do is caution you not to test anything on a production system. Once you have mastered the basics, start playing with SELinux by enabling it on a test replica of your production box. Make sure the audit daemons are running and keep an eye on the error messages. Check any denials preventing services from starting. Play around with the boolean settings. Make a list of possible steps for securing your system, like creating new users mapped to least-privilged SELinux accounts or applying the right context to non-standard file locations. Understand how to decipher an error log. Check the ports for various daemons: if non-standard ports are used, make sure they are correctly assigned to the policy.

It will all come together with time and practice. :)