GNU/Linux >> Linux の 問題 >  >> Linux

デーモンがデフォルト以外の場所にあるファイルを使用できるように SELinux を構成する

背景

SELinux は、Linux システムに別のパーミッション チェック レイヤーを追加します。 SELinux が有効なシステムでは、通常の DAC パーミッションが最初にチェックされ、アクセスが許可されている場合は、SELinux policy 相談されます。 SELinux ポリシーがアクセスを拒否した場合、/var/log/audit/audit.log の監査ログにログ エントリが生成されます または auditd の場合は dmesg で システムで実行されていません。

SELinux は security context と呼ばれるラベルを割り当てます 、システム内のすべてのオブジェクト (ファイル、プロセスなど) に対して:

  • ファイル セキュリティ コンテキストを拡張属性に格納します。これらは ls -Z で表示できます .

    SELinux は、パス パターンをデフォルトのファイル コンテキストにマッピングするデータベースを維持します。このデータベースは、デフォルトのファイル コンテキストを手動で復元する必要がある場合、またはシステムのラベルが変更された場合に使用されます。このデータベースは semanage でクエリできます

  • プロセス 実行可能ファイルの実行時にセキュリティ コンテキストが割り当てられます (execve システムコール)。プロセス セキュリティ コンテキストは、ps Z $PID などのほとんどのシステム監視ツールで表示できます。 .

  • 他のラベル付きオブジェクトも存在しますが、この回答には関係ありません。

SELinux ポリシー ルールを含む コンテキスト間で許可される操作を指定します。 SELinux は ホワイトリスト で動作します ポリシーで明示的に許可されていないものはすべて拒否されます。参照ポリシーには多くのアプリケーションのポリシー モジュールが含まれており、通常は SELinux 対応ディストリビューションで使用されるポリシーです。この回答は主に、参照ポリシーに基づくポリシーの操作方法を説明しています。これは、ディストリビューション提供ポリシーを使用する場合に使用する可能性が最も高いものです。

通常のユーザーとしてアプリケーションを実行する場合、SELinux に気付かない可能性があります。これは、デフォルトの構成ではユーザーが unconfined に配置されるためです。 環境。 無制限で実行されているプロセス コンテキストにはほとんど制限がありません。制限のないコンテキストではユーザー シェルで問題なくプログラムを実行できるかもしれませんが、init システムを使用して起動すると、制限されたコンテキストでは動作しなくなる可能性があります。

典型的な問題

ファイルが既定以外の場所 (既定のポリシーに記載されていない場所) にある場合、多くの場合、問題は次の理由に関連しています:

  • ファイルのファイル コンテキストが正しくない/互換性がない :mv で移動したファイル ファイル セキュリティ コンテキストを含むメタデータを古い場所から保持します。新しい場所に作成されたファイルは、親ディレクトリまたは作成プロセスからコンテキストを継承しました。

  • 複数のデーモンが同じファイルを使用する :デフォルト ポリシーには、問題のセキュリティ コンテキスト間の相互作用を許可するルールが含まれていません。

セキュリティ コンテキストが正しくないファイル

ファイルが別のデーモン (または他の制限されたプロセス) によって使用されておらず、変更がファイルの保存場所のみである場合、SELinux 構成に必要な変更は次のとおりです。

  • ファイル コンテキスト データベースに新しいルールを追加する
  • 正しいファイル コンテキストを既存のファイルに適用する

デフォルトの場所のファイル コンテキストは、新しい場所のテンプレートとして使用できます。ほとんどのポリシー モジュールには、man ページ ドキュメントが含まれています (sepolicy manpages を使用して生成されます)。 ) アクセス セマンティクスを使用して可能な代替ファイル コンテキストを説明します。

ファイル コンテキスト データベースは正規表現構文を使用するため、重複する仕様を記述できます。適用されたコンテキストは最後に見つかった仕様であることに注意してください。

ファイル コンテキスト データベースに新しいエントリを追加するには:

semanage fcontext -a -t <type> "/path/here/(/.*)?"

新しいコンテキスト エントリがデータベースに追加された後、restorecon <files> を使用して、データベースからのコンテキストをファイルに適用できます。 . restorecon を実行中 -vn で フラグは、変更を適用せずにどのファイル コンテキストが変更されるかを示します。

データベースに新しいエントリを追加せずに新しいファイル コンテキストをテストする

コンテキストは chcon で手動で変更できます 道具。これは、ファイル コンテキスト データベースにエントリを追加せずに新しいファイル コンテキストをテストする場合に便利です。

chcon への引数で新しいファイル コンテキストが指定されます . --reference= で使用する場合 オプションを使用すると、参照ファイルのセキュリティ コンテキストがターゲット ファイルにコピーされます。

特定のコンテキストを使用する (default_t ):

chcon -t default_t <target files>

または参照を使用:

chcon --reference=<path to default location> <target files>

異なるファイル システムとマウント ポイントに関する注意

新しい場所が独自のマウント ポイントである場合、マウント オプションを使用してコンテキストを設定できます。マウント オプションで設定されたコンテキストはディスクに保存されないため、拡張属性をサポートしないファイル システムでも使用できます。

mount <device> <mount point> -o context="<context>"

異なるセキュリティ コンテキストで実行されているプロセスが同じファイルを使用できるようにする

オプション 1:ブール値

参照ポリシーには、booleans と呼ばれる調整可能なオプションが含まれています 、特定の追加ルールを有効/無効にします。それらの多くは、通常は同じファイルを使用しない異なるシステム デーモンの相互運用を可能にします。

可能なすべての調整可能なオプションとその説明のリストは、semanage boolean -l を使用して一覧表示できます . audit2allow また、どのブール値を有効にする必要があるかを直接伝えることもできます。

semanage を使用してブール値を有効/無効にするには :

semanage boolean --on <boolean name>
semanage boolean --off <boolean name>

ブール値は、ポリシーを変更する最も簡単な方法です。ただし、ブール値を切り替えても、考えられるすべての状況に対処できるわけではありません。一部のブール値は、非常に幅広いアクセスを許可し、過度に寛大です。

オプション 2:新しいモジュールでポリシーを拡張

アクセスを許可するブール値が存在しない場合は、カスタム モジュールを追加してポリシーを変更する必要があります。

アクセスを許可するために必要なルールを追加する単純なモジュールは、audit2allow を使用してログ ファイルから生成できます。 次の手順で:

<オール>
  • デーモンのドメインを設定します (セキュリティ コンテキスト) を 許可モード に変更 .許可モードでは、ポリシーは強制されません 、しかし、ポリシーが通常拒否するアクセスでログが生成されます。

    semanage permissive -a <domain>
    
  • デーモンを通常の操作でテストして、ログ エントリを生成します。

  • 新しいポリシー モジュールを作成して挿入します。

    audit2allow -a -M <name>
    semodule -i <name>.pp'
    
  • 強制モードを再度有効にします

    semanage permissive -d <domain>
    
  • この方法は、関係するセキュリティ コンテキストが少ない場合に最適です。複雑な構成では、おそらく独自のポリシー モジュールを作成する必要があります。開始するためのリソースには、gentoo wiki と参照ポリシー API ドキュメントがあります。


    このコマンドで:

    # semanage fcontext -l /oldpath/
    

    システム内のフォルダーでデフォルトの SElinux コンテキストを確認できるため、そのコマンドを使用すると、そのデーモン フォルダーのデフォルトのコンテキストを確認できます。

    そのため、コンテンツの移動先のディレクトリで構成する必要がある SELinux コンテキストを確認できます。

    デーモン フォルダーに次のコンテキストがあることがわかったとします (これは apache コンテキストです):

    # semanage fcontext -l
    ...
    /var/www(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
    

    次に、これらのコンテキストを次のように新しいパスに適用します (Apache デーモンのデフォルト セキュリティ コンテキストの例)

    # semanage fcontext -a -t httpd_sys_content_t '/newpath(/.*)?'
    

    それを行った後、コンテンツが既に新しいパスにあることを考慮して、そのコンテキストを取得するために、そのパスの下にあるすべてのものを強制する必要があります:

    # restorecon -RFvv /newpath
    

    次のコマンドを使用して、機能したかどうかを確認できます:

    # ls -Zd /newpath/
    

    ディレクトリまたはファイルを mv すると、セキュリティ コンテキストが維持されることに注意してください。フォルダーまたはディレクトリを cp すると、コンテキストが親のコンテキストに設定されます。

    特定のソフトウェアのマニュアル ページを確認する必要がある場合は、次の方法でマニュアル ページをインストールできます。

    # yum install -y selinux-policy-devel
    

    このコマンドを実行して、man db のインデックスを再作成することを忘れないでください:

    # mandb
    

    次に、これを実行して、すべての selinux man ページを確認します。

    # man -k selinux
    

    そのパッケージをインストールする前と後にこのコマンドを実行して、違いを確認してください:

    # man -k selinux | wc -l
    

    Linux
    1. Linuxで特定のサイズのファイルを作成するには、fallocateコマンドを使用します

    2. Logrotateを使用してログファイルを管理する方法

    3. SELinux ファイルのラベル付けと SELinux コンテキストについて

    1. ファイル名に / を使用できますか?

    2. rsync がローカル ファイルにデルタ転送を使用しないのはなぜですか?

    3. 構成ファイルのバージョン管理に git を使用するのは良い考えですか?

    1. LinuxとWindows間でSAMBAサーバーを構成してファイルを転送する方法

    2. Inotifywaitを使用して、特定の拡張子のファイルを作成するためのディレクトリを監視する方法は?

    3. 構成コマンドを実行できません:「そのようなファイルまたはディレクトリはありません」?