SELinux-システムの操作の説明と機能。 パート1

Habré上のSELinuxについてはすでに書いていますが、このシステムに関する詳細なマニュアルはそれほど多く公開されていません。 本日、システムに関する情報から柔軟なポリシー設定まで、SELinuxに関する詳細なマニュアルを公開します。

投稿を理解しにくい「シート」にしないために、マニュアルを2つの部分に分けることにしました。 最初は、システム自体とその機能の一部について説明します。 2つ目は、ポリシーの設定に関するものです。 ここで最初の部分を公開し、少し後に2番目の部分を公開します。

1.はじめに

SELinux（SELinux）はカーネルレベルのアクセス制御システムです。 このシステムは、CentOSの4番目のバージョンで初めて登場し、バージョン5および6では、実装が大幅に補完および改善されました。 これらの改善により、SELinuxは多くの緊急タスクを効果的に解決できるユニバーサルシステムになりました。 古典的なUnixの権利システムが最初に適用され、この最初のチェックに成功した場合にのみ制御がSELinuxに転送されることを覚えておく価値があります。

1.1いくつかの関連タスク。

SELinuxの実際的な価値を理解するために、標準のアクセス制御システムが不十分な場合のいくつかの例を見てみましょう。 SELinuxが無効になっている場合、DAC（選択的アクセス制御）またはACL（アクセス制御リスト）を含む従来の任意アクセス制御システムのみにアクセスできます。 つまり、ユーザーおよびユーザーグループのレベルで書き込み、読み取り、実行の権限を操作することについて話しているが、これは場合によっては完全に不十分な場合がある。 例：



-管理者はユーザーのアクションを完全に制御できません。 たとえば、ユーザーは他のすべてのユーザーに、SSHキーなどの独自の機密ファイルを読み取る権利を与えることができます。



-プロセスはセキュリティ設定を変更できます。 たとえば、ユーザーのメールを含むファイルは特定の1人のユーザーのみが読み取り可能にする必要がありますが、メールクライアントはアクセス権を非常に適切に変更できるため、これらのファイルは誰でも読み取り可能です。



-プロセスは、それらを起動したユーザーの権限を継承します。 たとえば、トロイの木馬に感染したバージョンのFirefoxは、ユーザーのSSHキーを読み取ることができますが、理由はありません。



実際、選択的アクセス制御（DAC）の従来のモデルでは、ユーザーとスーパーユーザーの2つのアクセスレベルのみが適切に実装されています。 各ユーザーに必要な最小限の特権を設定できる簡単な方法はありません。

もちろん、古典的なセキュリティモデルの枠組み内でこれらの問題を回避する方法はたくさんありますが、どれも普遍的ではありません。

1.1.1 SELinuxで使用される基本用語：

ドメイン -プロセスが実行できるアクションのリスト。 通常、ドメインは、プロセスが機能できる最小のアクションセットとして定義されます。 したがって、プロセスの信用が失われた場合、攻撃者は大きな損害を与えることはできません。



ロール -適用できるドメインのリスト。 ドメインがロールのドメインリストにない場合、このドメインからのアクションは適用できません。



タイプ -オブジェクトに関連して有効なアクションのセット。 このタイプは、パイプ、ディレクトリ、およびファイルに適用でき、ドメインはプロセスに適用できるという点で、ドメインとは異なります。



セキュリティコンテキスト -すべてのSELinux属性-ロール、タイプ、およびドメイン。

1.2従来のセキュリティモデルの問題を解決する。

SELinuxは、各サービス、ユーザー、およびプログラムに最低限必要な特権のモデルをより厳密に守ります。 システムの各要素が機能するために不可欠な権限のみを持つ場合、デフォルト設定は「禁止モード」です。 ユーザー、プログラム、またはサービスがファイルを変更しようとしている、または明らかに解決する必要のないリソースにアクセスしようとしている場合、単にアクセスが拒否され、そのような試みがログに記録されます。







SELinuxはカーネルレベルで実装されるため、アプリケーションアプリケーションは、この強制アクセス制御システムのバージョン、その動作の機能などについてまったく何も知らない可能性があります。 適切な構成の場合、SELinuxはサードパーティのプログラムとサービスの機能に影響を与えません。 ただし、アプリケーションがこのアクセス制御システムのエラーメッセージを傍受できる場合は、同じアプリケーションを使用することの利便性が大幅に向上します。 実際、保護されたリソースまたはファイルにアクセスしようとすると、SELinuxは「アクセス拒否」ファミリーからメインアプリケーションにエラーを送信します。 ただし、SELinuxから受信したシステムコールのリターンコードを使用するアプリケーションはわずかです。



SELinuxを使用して、システム全体のセキュリティを強化する方法を確認する例を次に示します。



-sshキーを読み取ることができるプログラムのリストを作成および構成します。



-メールクライアントを介したデータへの不正アクセスの防止。



-ユーザーのホームフォルダーで機能するために必要なファイルとフォルダーのみを読み取れるようにブラウザーを構成します。

2. SELinuxの動作モード

SELinuxには3つの主要な動作モードがあり、デフォルトでは強制モードが設定されています。 これはかなり厳しいモードであり、必要に応じて、エンドユーザーにとってより便利なモードに変更できます。



Enforcing ：デフォルトモード。 このモードを選択すると、現在のセキュリティポリシーに何らかの形で違反するすべてのアクションがブロックされ、違反する試みがログに記録されます。



Permissive ：このモードを使用すると、現在のセキュリティポリシーに違反するすべてのアクションに関する情報がログに記録されますが、アクション自体はブロックされません。



無効 ：強制アクセス制御を完全に無効にします。



[管理]メニュー（system-config-selinux）で利用できる特別なGUIツールを使用して、現在のモードと他のSELinux設定を表示（および必要に応じて変更）できます。 コンソールでの作業に慣れている場合は、sestatusコマンドで現在のステータスを確認できます。

# sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: enforcing Policy version: 21 Policy from config file: targeted
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

getenforceコマンドを使用して、SELinuxステータスを確認することもできます。

setenforceコマンドを使用すると、強制モードと許容モードをすばやく切り替えることができ、変更は再起動せずに有効になります。 ただし、SELinuxを有効または無効にした場合、ファイルシステムにセキュリティラベルを再インストールする必要があるため、再起動が必要です。

各システムブートで適用されるデフォルトモードを選択するには、ファイル/ etc / selinux / configの行「SELINUX =」の値を設定し、「enforcing」、「permissive」、「disabled」のいずれかのモードを設定します。 たとえば、「SELINUX = permissive」です。

3. SELinuxポリシー

前述したように、SELinuxはデフォルトで強制モードで動作します。許可されているアクション以外のアクションが自動的にブロックされ、各プログラム、ユーザー、またはサービスが機能するために必要な権限のみを持ち、それ以上はありません。 これはかなり厳しいポリシーであり、プラス（最高レベルの情報セキュリティ）とマイナス（マイナス）の両方があります。このモードでシステムを構成すると、システム管理者にとって人件費が高くなります。少なくとも重要な方法で。 このアプローチはエンタープライズセクターでは受け入れられますが、エンドユーザーコンピューターでは受け入れられません。 多くの管理者は、ワークステーションでSELinuxをオフにして、このような問題が発生しないようにします。







これを回避するために、たとえばhttpd、named、dhcpd、mysqldなどの主要なアプリケーションおよびサービスについて、攻撃者が重要なデータにアクセスできないように事前設定されたターゲットポリシーが定義されています。 ポリシーが定義されていない同じアプリケーションがunconfined_tドメインで実行され、SELinuxによって保護されません。 したがって、正しく選択されたターゲットポリシーは、ユーザーに不必要な問題を引き起こすことなく、許容可能なレベルのセキュリティを実現できます。

4. SELinuxのアクセス制御

SELinuxは、次のアクセス制御モデルを提供します。



Type Enforcement（TE）：ターゲットポリシーで使用されるプライマリアクセス制御メカニズム。 最下位レベルで詳細に権限を管理できます。 システム管理者にとって最も柔軟性がありますが、最も時間がかかるメカニズムです。



役割ベースのアクセス制御（RBAC）：このモデルでは、アクセス権は役割として実装されます。 役割は、システムの他の部分に対してシステムの1つ以上の要素によって特定のアクションを実行する許可と呼ばれます。 本質的に、RBACはTEをさらに発展させたものです。



マルチレベルセキュリティ（MLS）：すべてのシステムオブジェクトに特定のアクセスレベルが割り当てられるマルチレベルセキュリティモデル。 アクセスの許可または拒否は、これらのレベルの比率によってのみ決定されます。



SELinux内のすべてのプロセスとファイルにはセキュリティコンテキストがあります。

/var/www/html/index.htmlにあるApache Webサーバーの開始ページを詳細に見て、実際のコンテキストを見てみましょう。

 $ ls -Z /var/www/html/index.html -rw-r--r-- username username system_u:object_r:httpd_sys_content_t /var/www/html/index.html
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

標準のファイル許可に加えて、SELinuxセキュリティコンテキストsystem_u：object_r：httpd_sys_content_tを確認できます。



コンテキストは、user：role：type：mlsに基づいていますが、user：role：typeフィールドは表示されますが、mlsフィールドは非表示です。 ターゲットポリシー、この場合はhttpd_sys_content_tも確認できます。



次に、「httpd」プロセス（Apache Webサーバー）のSELinuxセキュリティコンテキストを検討します。

 $ ps axZ | grep httpd system_u:system_r:httpd_t 3234 ? Ss 0:00 /usr/sbin/httpd
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、このプロセスはhttpd_tドメインで実行されています。



それでは、ホームディレクトリのファイルセキュリティコンテキストを見てみましょう。

 $ ls -Z /home/username/myfile.txt -rw-r--r-- username username user_u:object_r:user_home_t /home/username/myfile.txt
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ファイルのタイプはuser_home_tであることがわかります。このタイプはデフォルトでホームディレクトリ内のすべてのファイルに割り当てられます。

アクセスは同じタイプの要素間でのみ許可されるため、Apache Webサーバーはhttpd_sys_content_tタイプの/var/www/html/index.htmlファイルを問題なく読み取ることができます。 同時に、Apacheはhttpd_tドメインで実行されており、userid：usernameフィールドが入力されていないため、home / username / myfile.txtファイルにアクセスできませんが、このファイルはターゲットが定義されていないプロセスで読み取り可能です政治。 したがって、Apache Webサーバーがハッキングされた場合、攻撃者はファイルにアクセスしたり、httpd_tドメインにないプロセスを開始したりすることはできません。

5. SELinuxのトラブルシューティング

遅かれ早かれ、SELinuxが何かへのアクセスを拒否する状況に直面すると、状況が発生します。 アクセスが拒否される主な理由はいくつかあります。



-誤ってマークされたファイル。

-プロセスが間違ったコンテキストで実行されています

-政治の間違い。 このプロセスでは、ポリシーの作成時に考慮されなかったファイルへのアクセスが必要です。

-侵入の試み。



アクセス拒否の最初の3つの理由は非常に簡単に解決されますが、侵入の試行中にアラームが鳴り、ユーザーに通知が送信されます。

問題に対処するには、SELinuxログを参照してください。 デフォルトでは、監査プロセスによって/var/log/audit/audit.logファイルに書き込まれます。 このプロセスが開始されない場合、SELinuxは/ var / log / messagesファイルにログインします。この場合、すべてのアクセス制御システムメッセージはAVCキーでマークされます。これにより、たとえば必要な行をすばやくフィルタリングできます。 grepコマンドを使用します。

最新のディストリビューション（CentOS 5以降）には、SELinuxログを便利で使いやすい方法で表示できるグラフィカルユーザーインターフェイスを備えたユーティリティが含まれています。 sealert -bと入力して、コンソールから呼び出すことができます。 このユーティリティはsetroubleshootパッケージの一部です。 Xサーバーが実行されていない場合、次のコマンドを使用して、わかりやすくわかりやすいレポートを生成できます。

 sealert -a /var/log/audit/audit.log > /path/to/mylogfile.txt
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

5.1ファイルセキュリティコンテキストラベルの変更。

chconコマンドを使用すると、chownおよびchmodコマンドを使用して標準のアクセス制御システムの一部としてファイルの所有者またはファイルへのアクセス権を変更できるのと同じ方法で、ファイルまたはディレクトリのSELinuxコンテキストを変更できます。







いくつかの例を見てみましょう。

Apache Webサーバーがシステムにインストールされており、サイトが保存されているフォルダー（デフォルトでは/ var / www / html /）を、たとえば/ html /で変更し、このディレクトリにindex.htmlファイルを作成する必要があるとします。

 # mkdir /html # touch /html/index.html # ls -Z /html/index.html -rw-r--r-- root root user_u:object_r:default_t /html/index.html # ls -Z | grep html drwxr-xr-x root root user_u:object_r:default_t html
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

上記では、セキュリティコンテキストの一部として/ htmlディレクトリと/html/index.htmlファイルの両方がdefault_t型であることがわかります。 これは、Apacheを起動してこのディレクトリまたはファイルの操作を開始しようとすると、SELinuxがアクセスを拒否することを意味します。 Apacheとやり取りするファイルの正しいセキュリティコンテキストはhttpd_sys_content_tであるため、これは完全に正しいでしょう。

コンテキストを変更し、すべてが正しく行われたかどうかを確認します。

 # chcon -v --type=httpd_sys_content_t /html context of /html changed to user_u:object_r:httpd_sys_content_t # chcon -v --type=httpd_sys_content_t /html/index.html context of /html/index.html changed to user_u:object_r:httpd_sys_content_t # ls -Z /html/index.html -rw-r--r-- root root user_u:object_r:httpd_sys_content_t /html/index.html # ls -Z | grep html drwxr-xr-x root root user_u:object_r:httpd_sys_content_t html
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

各ファイルと各ディレクトリを手動で処理する必要はありません。単にオプションを使用して、-Rディレクトリを再帰的に走査できます。

 # chcon -Rv --type=httpd_sys_content_t /html
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

セキュリティコンテキストへのこのような変更は、再起動間で保持されますが、ファイルシステムラベルを変更すると、変更は消えます。 メンテナンスと運用のプロセスでは、これは珍しいことではありません。 この状況での正しいソリューションは、（もちろんテスト後）追加のルールを作成し、ローカルルールと組み合わせることです。 したがって、基本ルールよりも優先度が高くなります。



ファイルシステムのラベルを変更した後でもSELinuxが正常に動作するように、GUIインターフェイスでSELinuxを管理するツールとコンソールユーティリティsemanageの両方を使用できます。

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

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

上記の例では、httpd_sys_content_tコンテキストを/ htmlディレクトリ内のすべてのファイルに割り当てました。

5.2 SELinuxセキュリティコンテキストの復元。

restoreconコマンドを使用すると、セキュリティコンテキストをデフォルトで割り当てられたものに変更できます。

繰り返しますが、例としてApache Webサーバーを使用します。 ユーザーが自分のホームディレクトリにあるindex.htmlファイルのコピーを編集し、（mvコマンドを使用して）サイトが格納されているディレクトリ（/ var / www / html）に移動したとします。



コピー（cpコマンド）する場合、ファイルセキュリティコンテキストは宛先ディレクトリコンテキストと一致し、移動中はセキュリティコンテキストがソースコンテキストと一致することに注意してください。 もちろん、chconコマンドを使用してセキュリティコンテキストを変更できますが、移動したファイルは/ var / www / htmlディレクトリにあるため、このディレクトリ内のすべてのファイルのコンテキスト設定を単純に復元できます。



index.htmlファイルのコンテキストのみを復元するには、次のコマンドを使用できます。

 # restorecon -v /var/www/html/index.html
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ディレクトリ全体を再帰的にトラバースし、そこに含まれるすべてのファイルのコンテキストを変更する場合は、次のコマンドを使用します。

 # restorecon -Rv /var/www/html
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

5.3ファイルシステム全体のラベルの変更。

ファイルシステム全体にセキュリティラベルを再インストールする必要がある場合があります。 ほとんどの場合、この操作は、システムがしばらくオフになった後、SELinuxが再びオンになったときに実行されます。 これは、ポリシー管理のタイプを厳格に変更する場合にも必要です（この場合、すべてのプロセスは独自の特別なドメインで動作し、unconfined_tドメインでは誰も動作できません）。



次回の再起動時にファイルシステムを自動的に再配布するには、次のコマンドを入力します。

 # touch /.autorelabel # reboot
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

場合によっては、自動再パーティション分割が機能しないことがあります（ほとんどの場合、SELinuxシステムをオフにしたディストリビューションが更新された場合）。 この場合、次のコマンドを使用します。

 # genhomedircon # touch /.autorelabel # reboot
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

5.4ポートへのアクセスの提供。

多くの場合、Apacheのようなサービスが非標準ポートでリッスンし、着信接続を受け入れることができるようにしたいです。 基本的なSELinuxポリシーを使用すると、サービスにしっかりと接続されている事前定義されたポートにのみアクセスできます。 Apacheがポート81でリッスンするようにしたいとします。 この場合、semanageコマンドを使用してルールを追加する必要があります。

 # semanage port -a -t http_port_t -p tcp 81
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

SELinuxがアクセスを提供するポートの完全なリストは、次のように表示できます。

 # semanage port -l
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

マニュアルの第2部では、システムポリシーを柔軟に構成する機能を示します。