ルートにsetuidが設定されているユーティリティがデバッグ可能である場合、どのようにしてセキュリティを確保できますか？
今日、私はユーザーの権利の分離についての私の精神モデルを破った何かをユニで聞いた。すなわち、私はそれを聞いた：
実行権限のあるすべてのプログラムを自由にデバッグできます。setuidがrootに設定されているものも含みます。
これは、たとえば、デバッガーでsuを実行できることを意味します。私はそれを試してみましたがうまくいきました：
gdb su
これは私にとって驚異的なことです。ユーザーの権利管理に関する以前のメンタルモデルを提示して、私が間違っている箇所を修正して、実際の状況を説明してもらえますか？
今日まで、私はそれを信じていました：
- 私のユーザーアカウントで実行されるものはすべて、定義上、「私のもの」です。つまり、そのようなプログラムでやりたいことは何でも自由に行うことができます。特にデバッグが可能です。つまり、プログラムがメモリに格納するすべてのデータを読み取って変更したり、実行中にパッチを適用したりすることもできます。
setuidが他のユーザーに設定されているプログラム-簡単にするためにrootであると仮定します-私のユーザーアカウントの権限を超える権限で実行しますが、見返りに、意図したことだけを実行することになっています：それ以上のものはセキュリティ違反です。したがって、これらのプログラムは実行できますが、by私のアカウントですが、それでもnderを所有するアカウントを実行します。つまり、権利管理のPOVから、あたかもそれらが実行されているかのように実行されます。彼らの所有者によって実行された-それで私は彼らのメモリを読んだり、彼らの実行を中断したりできず、彼らを自分の意志に曲げることができず、特にそれらをデバッグすることができない。
2番目の点は明らかに誤りです。しかし、私の（明らかに間違った）メンタルモデルによれば、これは、たとえば、suの下でgdbを実行すると、suが決定する瞬間をトラップできることを伴います。パスワードが正しい場合は、suのメモリのこのフラグメントを変更して、この基本的な質問への回答が肯定的であると信じるように強制し、実行を再開すると、私はルート権限を持っています。まあ、バイナリ作成者はコードを難読化してこれを困難にしようとするかもしれませんが、熟練した永続的な人はいつでもこれを克服でき、オープンソースであるため、これはsuには当てはまりません。
私のメンタルモデルはどこが間違っていますか？それは現実とどこが対立していますか？
通常、suを実行すると、（rootとして）setuidが実行されます。 gdbで起動すると、setuidビットは有効になりません（ptraceされているため）。したがって、正しいパスワードを入力したと確信しても、実際に新しいUIDを付与する権限はありません。この理由は、あなたが説明する正確な攻撃を軽減するためです。