目次にジャンプページナビゲーションにジャンプ: 前のページ[アクセスキーp]/次のページ[アクセスキーn]
documentation.suse.com / SELinuxのトラブルシューティング

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

発行日: 20/03/2025
概要

SELinuxがenforcingモードになっているシステムでアクセス拒否が発生し、アプリケーションを正しく実行できない場合があります。audit2allowまたはsetroubleshootを使用して、使いやすい方法で拒否メッセージを分析できます。

目的

この記事では、SELinuxが原因で発生するアクセス拒否を、システムのセキュリティを低下させることなく解決する方法について説明します。

所要時間

この記事の理解には30分ほどを要します。

目標

詳しく説明されているツールの1つを使用してSELinuxの拒否をデバッグできるようになります。

要件

  • SELinuxが有効になっている実行中のシステム。

1 /var/log/audit/audit.logファイル

 

デフォルトでは、SELinuxが原因で何かが動作していない場合、この旨を示すログメッセージが/var/log/audit/audit.logファイルに送信されます。

注記
注記: 空の/var/log/audit/audit.log

空の/var/log/audit/audit.logが表示される場合、通常はauditdサービスが実行されていないことを意味します。この場合は、次の手順を実行します。

  1. auditdサービスを開始します。 

                > 
            sudo
            systemctl start auditd

  2. 次のコマンドを使用して、システムのターゲットでサービスを有効にします。 

                > 
            sudo
            systemctl enable auditd

/var/log/audit/audit.logファイルには、アクセス拒否、サービスイベントなどのメッセージが保存されます。

例 1: 「/etc/audit/audit.logの行の例」で、/var/log/audit/audit.logの内容の部分的な例を確認できます。

例 1: /etc/audit/audit.logの行の例
 
type=DAEMON_START msg=audit(1348173810.874:6248): auditd start, ver=1.7.7 format=raw kernel=3.0.13-0.27-default auid=0 pid=4235 subj=system_u:system_r:auditd_t res=success
type=AVC msg=audit(1348173901.081:292): avc:  denied  { write } for  pid=3426 comm="smartd" name="smartmontools" dev=sda6 ino=581743 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=dir
type=AVC msg=audit(1348173901.081:293): avc:  denied  { remove_name } for  pid=3426 comm="smartd" name="smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state~" dev=sda6 ino=582390 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=dir
type=AVC msg=audit(1348173901.081:294): avc:  denied  { unlink } for  pid=3426 comm="smartd" name="smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state~" dev=sda6 ino=582390 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=file
type=AVC msg=audit(1348173901.081:295): avc:  denied  { rename } for  pid=3426 comm="smartd" name="smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state" dev=sda6 ino=582373 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=file
type=AVC msg=audit(1348173901.081:296): avc:  denied  { add_name } for  pid=3426 comm="smartd" name="smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state~" scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=dir
type=AVC msg=audit(1348173901.081:297): avc:  denied  { create } for  pid=3426 comm="smartd" name="smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state" scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=file
type=AVC msg=audit(1348173901.081:298): avc:  denied  { write open } for  pid=3426 comm="smartd" name="smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state" dev=sda6 ino=582390 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=file
type=AVC msg=audit(1348173901.081:299): avc:  denied  { getattr } for  pid=3426 comm="smartd" path="/var/lib/smartmontools/smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state" dev=sda6 ino=582390 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=file
type=AVC msg=audit(1348173901.309:300): avc:  denied  { append } for  pid=1316

単一のメッセージは次のようになります。 

  type=AVC msg=audit(1348173901.081:299): avc:  denied  { getattr } for  pid=3426 comm="smartd" path="/var/lib/smartmontools/smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state" dev=sda6 ino=582390 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=file

メッセージのすべての行をセクションに分割できます。たとえば、最終行のセクションは次のようになります。

type=AVC:

SELinuxに関連する監査ログのすべての行は、type=AVCのような、タイプの識別情報で始まります。type=SYSCALLのメッセージが別のタイプのメッセージの後に続いていて、msgの値が同じである場合、メッセージでイベントに関する詳細情報が提供されている場合があることに注意してください。

msg=audit(1348173901.309:300):

タイムスタンプです。エポック時間(1970年1月1日からの経過秒数)で記述されています。エポック時間表記のドットまでの部分に対してdate -dを使用すると、そのイベントの発生日時を確認できます。 

> date -d @1348173901
Thu Sep 20 16:45:01 EDT 2012
avc: denied { append }:

拒否された具体的なアクション。この場合、ファイルへのデータの追加がシステムによって拒否されました。監査ログファイルを参照中に、システムの他のアクション(write open、getattrなど)を確認できます。

for pid=1316:

アクションを開始したコマンドまたはプロセスのプロセスID。

comm="rsyslogd":

PIDに関連付けられていた特定のコマンド。

name="smartmontools":

アクションの対象の名前。

dev=sda6 ino=582296:

関係のあるファイルのブロックデバイスとiノード番号。

scontext=system_u:system_r:syslogd_t:

ソースコンテキスト。これはアクションの開始者のコンテキストです。

tclass=file:

対象のクラスの識別情報。

2 audit2allowを使用した/var/log/audit/audit.logの分析

 

/var/log/audit/audit.log内のイベントを自身で解釈する代わりに、audit2allowコマンドを使用できます。

このコマンドは、/var/log/audit/audit.logのわかりにくいログメッセージを分析するのに役立ちます。audit2allowのトラブルシューティングセッションは、常に3つの異なるコマンドで構成されます。まず、audit2allow -w -aを使用して、監査情報をより読みやすい方法で表示します。デフォルトでは、audit2allow -w -aはaudit.logファイルを処理します。audit.logファイル内の特定のメッセージを分析する場合は、そのファイルを一時ファイルにコピーして次のコマンドで分析します。 

      > 
      sudo
      audit2allow -w -i FILENAME
例 2: 監査メッセージの分析
 
> sudoaudit2allow -w -i testfile
type=AVC msg=audit(1348173901.309:300): avc:  denied  { append } for  pid=1316
comm="rsyslogd" name="acpid" dev=sda6 ino=582296
scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:apmd_log_t tclass=file
原因:

Type Enforcement (TE)許可ルールが欠落している。

このアクセスを許可するためのロード可能モジュールを生成するには、次のコマンドを実行します。 

            > 
            sudo
            audit2allow

具体的にどのルールによってアクセスが拒否されているかを確認するには、audit2allow ‑aを使用して、audit.log ファイルに記録されたすべてのイベントから強制ルールを表示するか、audit2allow -i FILENAMEを使用して、特定のファイルに保存したメッセージについてルールを表示できます。

例 3: アクセスを拒否している行の表示
 
> sudoaudit2allow -i testfile
#============= syslogd_t ==============
allow syslogd_t apmd_log_t:file append;

mymoduleという名前のSELinuxモジュールを作成し、このモジュールをロードして以前に拒否されたアクセスを許可できるようにするには、次のコマンドを実行します。 

      > 
      sudo
      audit2allow -a -R -M mymodule

audit.logファイルに記録されたすべてのイベントに対してこれを実行する場合は、-a -Mコマンド引数を使用します。特定のファイルにある特定のメッセージのみに対してこれを実行するには、次の例のように-i -Mを使用します。

例 4: 以前に拒否されたアクションを許可するポリシーモジュールの作成
 
> sudoaudit2allow -i testfile -M example
******************** IMPORTANT ***********************
To make this policy package active, execute:

semodule -i example.pp

audit2allowコマンドで示されているように、このモジュールを実行できるようになりました。実行するには、semodule -iコマンドに続けて、audit2allowによって作成されたモジュールの名前(上の例ではexample.pp)を使用します。

3 setroubleshootを使用したAVCメッセージの分析

 

使いやすい方法でAVC拒否メッセージを分析するには、setroubleshootツールを使用できます。

3.1 setroubleshootの概要

 

3.1.1 setroubleshootとは

 

setroubleshootは、カーネルからのSELinux監査イベントを収集し、これらのイベントを分析するツールです。このようなイベントが発生した場合、setroubleshootによって管理者に通知されます。

3.1.2 setroubleshootコンポーネント

 

SELinuxのトラブルシューティングプロセスには、以下のコンポーネントが必要です。これらのコンポーネントはすべてデフォルトでSUSE Linux Microにインストールされています。

  • setroubleshoot-serverでは、次のツールを提供します。

    • setroubleshootd - 受信要求とプラグイン定義を処理するメインデーモン。このデーモンはオンデマンドで有効化されるため、systemdサービスを介して実行する必要はありません。特権ユーザと専用のsetroubleshootユーザのみが管理できます。

    • ファイル/var/lib/setroubleshoot/setroubleshoot_database.xml内のアラートのデータベース。

    • sealert - /var/log/audit.logを分析するためのコマンドラインユーザインタフェース。

    • sedispatch - SELinux AVCメッセージをスキャンし、DBusメッセージに変換してからデーモンに渡す監査ディスパッチャ。

  • setroubleshoot-plugins - このプラグインは、AVCメッセージの分析に使用され、問題の解決方法に関する提案を提供します。

3.1.3 setroubleshootの動作

 

setroubleshootは、デーモンと分析プラグインで構成されます。プラグインが問題を検出すると、デーモンに問題が報告され、デーモンはこれが既知の問題であるかどうかを確認します。既知の問題ではない場合、新しい問題が、提案された解決策とともにデータベースに追加されます。

3.1.4 setroubleshootの利点

 

setroubleshootは、SELinuxでセキュリティ保護されたシステムの問題を解決するのに役立つ次の機能を備えています。

  • AVC拒否がある場合に管理者にアラートを送信する。

  • AVC拒否を自動的に分析する。

  • システム設定の調整や更新のインストールなど、考えられる修正を提案する。

  • 以前のアラートを参照する。

3.2 setroubleshootの構成

 

setroubleshootの設定を調整する必要はありませんが、デフォルト値の変更が必要な特定のユースケースに直面することがあります。以降のセクションでは、通常のユースケースについて説明します。

setroubleshootの設定ファイルは/etc/setroubleshootです。通常は、電子メール通知を設定する以外に設定を変更する必要はありません。ただし、設定を変更する必要がある場合は、このファイルを編集するか、setroubleshootdコマンドを使用して特定の項目を設定できます。コマンドの構文は次のとおりです。 

        # 
        setroubleshootd -c
SECTION.OPTION=VALUE

たとえば、from_addressオプションを設定するには、このコマンドを次のように実行します。 

        # 
        setroubleshootd -c
email.from_address="example@mail.com"

3.2.1 setroubleshootのログレベルの設定

 

デフォルトのログレベル(sealert_logとsetroubleshootd_logの値)はwarningに設定されています。ただし、この値を次のいずれかに設定できます。

critical

システムの機能を妨げる重大なエラーのみがログに記録されます。

error

システムに影響を及ぼす可能性のある重大なエラーが報告されます。

warning

予期しない症状が発生したり、近い将来に問題が発生する可能性があることを示します。ただし、システムは期待どおりに動作しています。

info

システムが正しく実行されていることの確認がログに記録されます。

debug

デバッグ用の詳細情報がログに記録されます。

3.2.2 電子メール通知を送信するためのsetroubleshootの設定

 

システムでAVC拒否が発生している場合に、setroubleshootから電子メール通知を送信できます。

これらの通知を受信するには、次の手順に従います。

  1. /etc/setroubleshoot/setroubleshoot.confを開きます。

  2. このファイルで、次の設定項目をニーズに合わせて調整します。

    smtp_host

    SMTPサーバがローカルホスト上で実行されていない場合、SMTPサーバのアドレスを入力します。

    smtp_port

    デフォルトは25です。通常、この値を調整する必要はありません。

    from_address

    送信者のアドレスを追加します。

    subject

    すべてのメッセージの汎用の件名を設定します。

    recipients_filepath

    通知の受信者リストの場所を指定します。

    use_sendmail

    SendMailを使用する場合、trueに設定します。

  3. メール受信者ファイルを、recipients_filepathオプションで定義したパスに作成します(デフォルトでは/var/lib/setroubleshoot/email_alerts-recipients)。

    各電子メールアドレスは1行に1つずつ記述する必要があります。コメントは#記号で指定します。

3.2.3 setroubleshootデータベースの設定

 

setroubleshootdデータベースのレコード数、その場所、またはファイル名のプレフィクスを変更できます。

database_dir

データベースのXMLファイルが存在するディレクトリの絶対パスを指定します。

filename

データベースファイル名のカスタムプレフィクスを設定します。設定すると、ファイル名はFILENAME_PREFIX_database.xmlのようになります。

max_alerts

データベース内のレコードの最大数を定義します。レコード数が無制限の場合は、0を指定します。

max_alert_age

設定した制限より古いアラートはデータベースから削除されます。year、month、day、hour、minute、secondの各単位は複数形でも使用でき、複数の単位を使用できます。たとえば、3 weeks 2 daysは23日に相当します。空白のままにした場合、制限はありません。

3.2.4 リモートサーバから情報を収集するためのsetroubleshootの設定

 

SELinuxの監査データをリモートサーバから収集するようにsetroubleshootを設定できます。そのためには、アドレスリストを設定します。

[listen_for_client] address_list

サーバ側に設定します。

[client_connect_to] address_list

クライアント側に設定します。

リストのアドレスは次の形式です。 

          [{FAMILY}]ADDRESS[:PORT_NUMBER]

ここで、{FAMILY}は、{inet}または{unix}%{path}sです。アドレスファミリがinetである場合は、オプションでポート番号を指定できます。それ以外の場合、ポート番号はdefault_port設定オプションで指定されたデフォルト値に設定されます。デフォルト値{unix}%{path}s hostnameは、ローカルのUnixドメインソケットをリスンすることを意味します。

3.3 /var/log/audit/audit.logの分析の実行

 

setroubleshootツールで監査ログファイルを分析できるようにするには、次のコマンドを実行します。 

        > 
        sudo
        sealert -a /var/log/audit/audit.log

次の出力例では、SSHDサービスに割り当てられているポート値が2つあります。 

100% done
found 1 alerts in /var/log/audit/audit.log
--------------------------------------------------------------------------------

SELinux is preventing sshd from name_bind access on the tcp_socket port 2222.

*****  Plugin bind_ports (92.2 confidence) suggests   ************************ 

If you want to allow sshd to bind to network port 2222
Then you need to modify the port type.
Do
# semanage port -a -t PORT_TYPE -p tcp 2222  1
    where PORT_TYPE is one of the following: ssh_port_t, vnc_port_t, xserver_port_t.

*****  Plugin catchall_boolean (7.83 confidence) suggests   ******************

If you want to allow nis to enabled
Then you must tell SELinux about this by enabling the 'nis_enabled' boolean.

Do
setsebool -P nis_enabled 1

*****  Plugin catchall (1.41 confidence) suggests   **************************

If you believe that sshd should be allowed name_bind access on the port 2222 tcp_socket by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'sshd' --raw | audit2allow -M my-sshd
# semodule -X 300 -i my-sshd.pp

Additional Information:
...

First Seen                    2024-02-07 14:26:27 UTC
Last Seen                     2024-02-08 03:30:12 UTC
Local ID                      b5cbdd75-3f8d-425d-af75-f6cbf1540ffd 

Raw Audit Messages
type=AVC msg=audit(1707363012.797:25): avc:  denied  { name_bind } for  pid=841 comm="sshd" src=2222 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket permissive=0


Hash: sshd,sshd_t,unreserved_port_t,tcp_socket,name_bind

1

bind_portsプラグインにより、この問題に最適な解決策が提供されます。