プロセスがそのuidを0（ルート）に設定するには何が必要ですか？
* NIXベースのOSはまったく新しいものです。私を困惑させることの1つは、プロセスまたはプログラムがsetuid(0)を実行してから、特権操作を実行し、通常のuidに戻る可能性があることです。
私の質問は、任意のプロセスがrootを所有するのを防ぐための* NIXのメカニズムは何ですか？
setuid(0)を呼び出す単純なCプログラムを作成すると、どの条件でその呼び出しが成功し、どのような条件で失敗しますか？
基本的な考え方は、プロセスはその特権を減らすことしかできないということです。プロセスは特権を取得できません。例外が1つあります。setuidまたはsetgidフラグが設定されているファイルからプログラムが 実行 するプロセスは、このフラグで表される特権を取得します。
このメカニズムでは、プログラムが昇格された特権で任意のコードを実行できないことに注意してください。昇格された特権で実行できる唯一のコードは、setuid/setgid実行可能ファイルです。
Rootユーザー、つまりID 0のユーザーは、何よりも特権が高くなっています。ユーザー0のプロセスは、何でも実行できます。 （グループ0は特別ではありません。）
ほとんどのプロセスは同じ特権で実行し続けます。ユーザーをログインさせる、またはデーモンを起動するプログラムは、rootとして起動し、すべての特権を削除して、目的のプログラムをユーザーとして実行します（ユーザーのログインシェルやセッションマネージャー、デーモンなど）。 Setuid（またはsetgid）プログラムはターゲットユーザーおよびグループとして動作できますが、多くの場合、これから説明するメカニズムを使用して、呼び出し側の権限と自分の追加権限を、実行している内容に応じて切り替えます。
すべての プロセスには3つのユーザーIDがあります ：realユーザーID（RUID）、有効ユーザーID（EUID）、および保存済みユーザーID（SUID）。アイデアは、プロセスが一時的に特権を取得し、必要がなくなったときにそれらを放棄し、再び必要になったときにそれらを取り戻すというものです。 groups にも同様のメカニズムがあり、実際のグループID（RGID）、実効グループID（EGID）、保存済みグループID（SGID）、および補足グループがあります。彼らが働く方法は次のとおりです：
- ほとんどのプログラムは、全体を通して同じ実際のUIDとGIDを保持します。主な例外は、ログインプログラム（およびデーモンランチャー）です。これらは、RUIDおよびRGIDをrootからターゲットユーザーおよびグループに切り替えます。
- ファイルアクセス、およびroot権限を必要とする操作については、有効なUIDとGIDを確認してください。特権プログラムは、特権操作を実行しているかどうかに応じて、有効なIDを切り替えることがよくあります。
- 保存されたIDにより、有効なIDを前後に切り替えることができます。プログラムは、有効なIDを保存されたIDと実際のIDの間で切り替える場合があります。
Root特権で特定のアクションを実行する必要があるプログラムは、通常、EUIDをRUIDに設定して実行しますが、特権を必要とするアクションを実行してseteuidを呼び出す前に、seteuidを呼び出してEUIDを0に設定します再びEUIDに戻り、その後RUIDに戻します。 seteuid(0)の呼び出しを実行するには、その時点のEUIDが0ではない場合でも、SUIDは0でなければなりません。
同じメカニズムを使用して、グループ特権を取得できます。典型的な例は、高いスコアのローカルユーザーを保存するゲームです。ゲームの実行可能ファイルはsetgid gamesです。ゲームが開始すると、EGIDはgamesに設定されますが、RGIDに戻り、ユーザーが通常許可されていないアクションを実行するリスクを回避します。ゲームがハイスコアを保存しようとすると、EGIDが一時的にgamesに変更されます。こちらです：
- ハイスコアファイルには通常のユーザーにはない特権が必要なため、ハイスコアファイルにエントリを追加する唯一の方法は、ゲームをプレイすることです。
- ゲームにセキュリティの脆弱性がある場合、最悪の場合、ユーザーに
gamesグループへのアクセス許可を付与し、ハイスコアをだますことができます。 - ゲームにバグがあり、プログラムが
setegid関数を呼び出すことにならない場合。ゲームに意図しないファイルへの書き込みのみを引き起こすバグ。その場合、ゲームはsetegidを呼び出さずにハイスコアファイルに書き込む権限がないため、ハイスコアでの不正行為は許可されません。 。
上記で書いたのは、基本的な従来のUnixシステムについての説明です。最新のシステムの中には、従来のUnix特権モデルを補完する他の機能を備えているものもあります。これらの機能は、基本的なユーザー/グループの効果的な/実際のシステムに追加され、時々それと相互作用します。これらの追加機能については詳しく説明しませんが、Linuxセキュリティモデルの3つの機能についてのみ説明します。
- 多くのアクションを実行するための権限は、ユーザーID 0ではなく capability を介して付与されます。たとえば、ユーザーIDを変更するには、ユーザーID 0ではなく機能
CAP_SETUIDが必要です。ユーザーID 0は、邪魔にならない限りすべての機能を受け取り、CAP_SETUIDで実行されているプログラムはroot権限を取得できるため、実際にはrootとして実行され、CAP_SETUIDを持つことは同等です。 - Linuxにはいくつかの セキュリティフレームワーク があり、そのプロセスがユーザーID 0として実行されている場合でも、プロセスが実行できることを制限できます。従来のUnixモデルや機能とは異なり、一部のセキュリティフレームワークでは、プロセスが実行可能ファイルのメタデータのフラグによるのではなく、セキュリティフレームワークの構成による
execveに対する特権。 - Linuxには sernamespaces があります。ネームスペースでrootとして実行されているプロセスは、そのネームスペース内でのみ特権を持っています。
ユーザーIDに加えて、プロセスも実効ユーザーIDに関連付けられます。 suのようなsetuidルートプログラムを実行すると、実効uidは0に設定されますが、実際のuidは変わりません。有効なuidは、名前が示すように、権限チェックに使用されるuidであり、実際のuidは単に「私たちが誰であるか」を伝えます。有効なuidがゼロに等しいプロセスは、setuid(0)を正常に呼び出して、実際のuidをゼロに変更できます。
Setuid（some_uid）が機能するためには、次の条件を満たす必要があります。
- 実行可能ファイルはsome_uidが所有する必要があります1。
- 実行可能ファイルには、setuidアクセス権が必要です。
Setuidアクセス許可は、chmodで付与または削除できます。
chmod u+s execuables_file_name
chmod u-s execuables_file_name
Setuidアクセス許可が付与されている場合、実行アクセス許可はsに置き換えられるため、ファイルアクセス許可を表示すると、setuidアクセス許可が表示されます。
> ll execuables_file_name
-rwsrwxr-x 1 root root 0 Sep 30 17:23 execuables_file_name*
何らかの理由で所有者ユーザーに実行権限がない場合は、代わりに大文字のSとして表示されます。
> ll execuables_file_name
-rwSrwxr-x 1 root root 0 Sep 30 17:23 execuables_file_name*
スクリプトはまったく別の獣です であることに注意してください。
徹底的な 許可へのガイド 。
1.プロセスを開始したユーザーIDに移行する場合、setuid（some_uid）も成功します