☰

無制限のSELinuxユーザー（root）がシステムにポリシーをインストールするのを防ぐ

tag-icon • tag-icon permissions selinux
無制限のSELinuxユーザー（root）がシステムにポリシーをインストールするのを防ぐ

インストール後に制限されていない（または他のオプション）、ユーザーの後続のSELinuxポリシーのインストールを無効にするSELinuxポリシーを作成しようとしています。これを行うにはいくつかの方法があるようです。

  1. ユーザーがポリシーをインストールできないようにsemoduleの使用を無効にします。 semoduleには「semanage_exec_t」SELinuxタイプがあります。オブジェクトを使用しています。ドメイン変換ここで。
  2. SELinuxの使用セキュリティレベル。

最初の結論は「domain_auto_trans」マクロを使用しようとしています。25未満のポリシーバージョンにはマクロは適用されません。。私は24を持っています。ポリシーバージョン28で確認できましたが、期待どおりに機能します。しかし、このように見えました。

    policy_module(semanage_access_deny_label_B, 1.0.0)
    require {
       type unconfined_t, semanage_exec_t, semanage_t;
       role object_r;
    }
    domain_auto_trans (unconfined_t, {semanage_exec_t semanage_t}, user_t);

2番目の結論のTEファイルは次のとおりです。

policy_module(semanage_access_deny, 1.0.0)
require {
   type unconfined_t;
   role object_r;
   class security { compute_av compute_user compute_relabel 
   compute_create setenforce check_context load_policy setbool };
}
allow unconfined_t self: security compute_user;
neverallow unconfined_t self: security { compute_av setenforce check_context load_policy setbool };

最初の方法は現在SELinuxバージョンでのみ機能していますが、2番目の方法は正常にコンパイルして適用しましたが、私が計画したようには行われませんでした（実際には何もしませんでした）。その場合、問題は、インストール後に選択したユーザーの後続のSELinuxポリシーのインストールを無効にし、現在および以前のSELinuxバージョンの両方に適用されるポリシーを作成する方法です。

答え1

最初のモジュールに問題があります：rootユーザー無制限_tselinux ポリシーの変更を許可する権限とルールがまだあります。カスタムポリシーは新しい自動コンバージョンにのみ適用されます。semanage_exec_t到着 user_t。で処理user_tドメインはポリシーを変更できないため、semodule待機semanageは失敗します。ただし、信頼できないドメイン内のすべてのプログラムはまだポリシーを変更できます。また、ルートはその項目のラベルを再指定することもできます。semanage_exec_t実行するには、バイナリを無制限の種類で表示します。

2番目のポリシーモジュールは何もしません。絶対に許可されていませんルールはコンパイラによって検証され、コンパイルポリシーにルールは生成されません。使用できません絶対に許可されていません削除/ブラックリストルールはロードされたポリシーに含まれています。否定的なこの方法で使用できるSELinuxポリシー言語の宣言）。

競合がある場合は、ポリシーのコンパイルでエラーが発生して失敗する必要があります。許可するそして絶対に許可されていませんルール。 ~によると文書、絶対に許可されていませんルールはポリシーモジュールで使用できますが、チェックを有効にするにはルールをexpand-check1に設定する必要がありますsemanage.conf（おそらくモジュールが正常にコンパイルされる理由です）。

ロードされたSELinuxポリシーの修正を防ぐために問題を解決するいくつかの方法は次のとおりです。

  • 使用secure_mode_policyloadブール値：

    システムがポリシーのロード、適用モードの設定、およびブール値の変更を許可するかどうかを決定するために使用されるブール値。

    同様にsecure_mode_insmodブール値は、追加のカーネルモジュールがロードされるのを防ぎます。一度オンにすると、実行中のシステムでこれらのブール値をオフにすることはできません（オフにするには再起動が必要です）。

  • ユーザー設定より制限された地域（例：user_t）、これはロードされたポリシーの変更を許可しません。surootとして/ switchingを使用すると、sudoより高い権限を持つSELinuxユーザーに昇格されず、同じSELinux施行制限が維持されます。

  • あなた自身のSELinuxユーザーを作成してください。デプロイメントによって提供されるSELinuxユーザーに基づいて、これに基づいて行うことができます（デプロイメントのポリシーソースのダウンロード）。制限されていないユーザーの代わりに、一部の制限付きユーザーをテンプレートとして使用することを検討し、あまりにも広範な権限を付与しないようにする必要がある権限のみを追加する必要があります。

    また、一部の制限付きアクセス（変換/規則）のみを付与する必要がある場合は、制限されたユーザーに必要なアクセス権を付与するポリシーモジュールを作成できます。

答え2

新しいポリシーを「インストール」する場合、最終的には/etc/selinux/TYPE/policy/policy.*ファイルを「書き込み」および「ラベルの上書き」できるユーザーへのアクセスを制限することに要約されます。

目標タイプを決定します。 SELinuxポリシー分析スイートを使用して、このタイプのファイルに「書き込み」および「説明」できる内容を決定します。次に、ポリシーをインストールしたくないプロセスがその種類のファイルに直接または間接的にアクセスできないことを確認してください。

また、ポリシーをインストールしたくないすべてのプロセスに「security setenforce」へのアクセス権がなく、物理アクセス権がないことを確認したい場合があります。そうしないと、これらのプロセスがSELinuxをバイパスする可能性があるためです。

関連情報