Linuxカーネルを設定しようとしています。混乱していますMake audit loginuid immutable (AUDIT_LOGINUID_IMMUTABLE) [N/y/?]。
ヘルプは次のように言います。
+config AUDIT_LOGINUID_IMMUTABLE
+bool "監査ログイン UID を変更できないように設定"
+AUDIT によって異なる
+help
+タスクに
ログイン ID を設定するために +CAP_SYS_AUDITControl が必要な場合、またはタスクに特別な権限が必要ない場合、設定オプション切り替えられますが、
+以前にのみ許可する必要があります。 loginuid 設定 絶対に
設定しないでください。
ログインサービスを再起動するためにsystemdまたは同様の中央プロセスを使用するシステムでは、これをtrueに設定する必要があります。
管理者がプロセスを直接停止して開始する必要がある場合が多い古いシステムでは、
falseに設定する必要があります。これを true に設定すると、
+1 はログイン操作から潜在的に危険な機能を削除することができますが、
以前の init システムとは逆互換ではない可能性があります。
loginuidこの特定のプロセスがより多くの権限と権限を取得するように変更できるのと同じですか？euid
そうでない場合は、より簡単な言語で説明できますか？より多くの権限でプロセスを開始しsudo [process]たり、実行中にプロセスにさらに権限を付与したりするのと同じですか？または、suこの設定を実行できる人（sysadminまたはroot）のみを使用できますか？
ベストアンサー1
許可された回答が正しくありません。私の答えはそれほど正確ではなく理解するのは簡単ではありませんが、共有する価値があるようです。 :) このカーネルオプションは、loginuidが設定されず、変更されていない状態で誰でも「echo 0 > /proc/self/loginuid」を実行できるか、またはこの値を変更するには現在の値に関係なく特定の機能が必要かどうかを決定します。これが真の場合（通常はユーザーがrootであることを意味します）、loginuidは設定されていない場合にのみ変更できます。許容される回答が不正確な理由は、sudoとsuが通常suidルートであるためです。バイナリを別の有効なUIDに切り替えることを可能にするためのsuidルート。ほとんどのLinuxシステムでは、rootユーザーはデフォルトですべての機能を持っています。したがって、これがfalseの場合、これらのプログラムにはloginuid属性を切り替える機能もあります。これが本当で、システムが正しく設定されている場合は、ssh / login / whateverを介してログインシェルにloginuidを設定する必要があり、何も値を変更できません。
システムの起動/初期化中はloginuid属性は設定されません。通常、「エントリポイント」サービスの pam_loginuid モジュールによって最初に設定されます。したがって、sshとログインを設定して値を設定します。これは誰かが「ログイン」できるようにすることなのでloginuidになります。たとえば、これは新しいログインではないため、sudo pamスタックにモジュールを含めません。つまり、ログイン後にUIDが切り替わります。 loginuidの目的は、ログイン時間からユーザーを追跡することです。 suまたはsudoを使用してアカウントを切り替えた後でも、監査デーモンを使用すると、特定のユーザーが実行しているプロセスを記録できます。 lognameユーティリティは、最新のシステムでこの属性を使用して、有効または実際のuid値に関係なく「ログインユーザー」を識別します（以前のシステムは制御端末を使用してutmpでログインイベントを検索します）。
ところで、プロセスは親プロセスからloginuid属性を継承します。
したがって、このパラメーターはloginuid属性を変更できるかどうかを制御します。 initの仕組みのため、systemdを参照してください。カーネルがinitを起動し、initにはloginuidはありません。その後、initはサービスを開始し、これらのサービスにはloginuidが設定されていません。一般的な System V init では、管理者はログインして「/etc/init.d/someservice restart」を実行できます。管理者のloginuid属性は、SSH経由でログインしてrootに切り替えるときに設定されます。次に、Loginuidを継承するinitスクリプトを実行します。 "loginuid immutable"の値が設定されている場合、initスクリプトまたは管理者はデーモンを起動し、lognuid属性を消去またはリセットする前にシステムコールを実行できなくなり、デーモンは管理者のloginuidとして実行され、監査ログなどを混乱させます。値が変更可能な場合は、特定のデーモンに対して適切な機能（/ sbin / serviceなど）を持つプロセスでシステムコール（audit_setloginuid（））を実行して、loginuidをクリアまたは合理的な値に設定できます。
systemd（そしてupstartと他のいくつかのinitシステム）が動作するように、管理者はinitスクリプトを直接実行しません。代わりに、管理者はinitプロセスにコマンドを送信し、それ自体で再起動（または他の）操作を実行します。 initには設定されていないloginuidがあるため、生成されたinitスクリプトは次のものを継承します。それ値（未設定）の場合、root以外のユーザーとして実行されていても、initスクリプトは独自のloginuidを設定できます。特別な機能が不要なため、一般ユーザーがすべての作業を実行できるため、より安全です。
したがって、分離されたinitシステムがある場合、loginuid属性が最初に設定されている場合、通常は非ルート項目は属性を変更する正当な理由がないため、本質的に不変に設定される可能性があります。
「これがあなたに何をもたらすのか」という質問に答えるにはあまりありません。 uidやeuidではなくloginuidに基づいてアクセスを許可するいくつかのプログラムがあるかもしれませんが、これはまれです。通常、アクセスはSELinuxコンテキスト、EUID、UID、またはプロセス機能に基づいて制御されます。 loginuid を 0 に変更しても役に立たず、リモートルートログインをキャプチャするように設計された監視システムを実行できます。 :) 一部のサイトでは、プロセスの実行/システムコールを追跡するために auditd を使用します。これらのサイトでは、有効なシステム監査ルールを得るために正確な loginuid が必要になる可能性があります。ただし、コンパイル中のカーネルについてこの質問をする場合は、これらのサイトのいずれかを実行しているわけではありません。 :)