passwdのようなSUIDプログラムだろうか setuid()を使用しています 関数呼び出し。ルート権限を削除するのはなぜですか？
これはどのような種類の攻撃に役立ちますか？バッファオーバーフロー？
承認された回答：
最初に、passwdが使用し、setuid()とは異なるsetuidビットについて説明します。 システムコール（passwdは使用しません）。この点に関して、質問にはおそらく混乱があります。
バッファオーバーフローに対する保護ではなく、脆弱 そのようなもの、または基本的に、攻撃者が悪意のある意図しない目的のために特権プロセスを使用できるようにするものなら何でも。これは、setuidビットが「特権の削除」の反対であるためです。 授与 ルート権限。ただし、プロセスに対してのみ 実際のユーザーではありません。これにはpasswdが含まれます 。
この形式のsetuidには、実行可能ファイルに設定されたファイルシステムsetuidビットが必要です。 passwd /etc/passwdの読み取りと書き込みには特権が必要なため、これがあります 。ただし、passwdに既知のセキュリティの脆弱性（たとえば、潜在的なオーバーフローエクスプロイト）がないことを願っています。ルートとして実行されるため、可能性があります 何でもする— 1つの特定のことだけを行うように設計されており、他のことを行うように設計されている場合を除き、 （繰り返しますが、うまくいけば）不可能です。
したがって、その意味でsetuidを使用することは、何に対しても保護することにはなりません 、しかし、潜在的な脆弱性は非常に重要なWRT setuid実行可能ファイルであるため、脆弱性に関連して議論されることがよくあります。
ただし、setuidビットは実際のuidではなくeuidを設定するため、実際にはseteuid()と並列になります。 システムコールとない setuid() 。
特権の削除に関する「setuid」の反対の形式があります。これには、実際のsetuid()が含まれます。 システムコールであり、setuidビットを必要としません。これは、rootとして実行されているプロセス（rootまたはsudoがプロセスを開始したため）がそのuidを特権の低いユーザーに変更する場合です。サーバーとデーモンは、起動時にroot権限が必要な場合（たとえば、特権ポートを開くため）にこれを行うことがよくありますが、その後は必要ありません。そうすれば、サーバーがその後ジャックされた場合、サーバーにはスーパーユーザー権限がありません。 setuid(0)を呼び出すことはできません ルート権限を取り戻します（ただし、set * e を使用すると可能です） * uid）。