Loading article…
Unix ライクなシステムでは、アクセス権フラグsetuidとsetgid ( set user identityとset group identityの略) [ 1 ]により、ユーザーは実行可能ファイルを、それぞれ実行可能ファイルの所有者またはグループのファイルシステム権限で実行したり、ディレクトリの動作を変更したりできます。これらは、コンピュータ システム上のユーザーが特定のタスクを実行するために一時的に特権を昇格させてプログラムを実行できるようにする場合によく使用されます。想定されるユーザー ID またはグループ ID の権限は必ずしも昇格されているとは限りませんが、少なくとも特定の権限です。
フラグsetuidと は、setgidシステム ファイルやデータベースを変更してログイン パスワードを変更するなど、ユーザーに通常付与されている権限とは異なる権限を必要とするタスクに必要です。[ 2 ]ただし、ネットワーク インターフェイスで制御パケットをping送信および受信する必要があるコマンドなど、追加の権限を必要とするタスクの中には、すぐには明らかにならないものもあります。
およびフラグは、ファイル、ディレクトリ、バイナリ実行可能ファイルsetuid、setgidまたは非バイナリ実行可能ファイルのいずれに適用されるかによって、異なる効果を持ちます。setuidおよびsetgidフラグは、バイナリ実行可能ファイルにのみ効果があり、スクリプト (Bash、Perl、Python など) には効果がありません。[ 3 ]
実行可能setuidファイルにまたはsetgid属性が設定されている場合、そのファイルを実行できるユーザーは、設定されているフラグに応じて、ファイルの所有者 (通常はroot ) および/またはファイルのグループの権限で自動的にファイルを実行します。[ 2 ]これは、ファイルを実行するプロセスの実効ユーザー IDをファイルの所有者に設定するか、ファイルを実行するプロセスの実効グループ IDをファイルのグループに設定することによって行われます。これにより、システム設計者は、通常ユーザーが実行を許可されない信頼できるプログラムの実行を許可できます。これらは必ずしも明らかではありません。たとえば、pingコマンドは、通常のユーザーがアクセスできないネットワーク権限へのアクセスを必要とする場合があります。そのため、別のシステムに ping する必要があるユーザーが、アカウントにパケット送信に必要な権限がなくても、ping を実行できるように、setuid フラグが付けられることがあります。
セキュリティ上の理由から、通常、システムによって、呼び出し元のユーザーが新しいプロセスを何らかの方法で変更すること（例えば、を使用したり、やptraceなどの環境変数を指定したり、昇格された権限を悪用するためにシグナルを送信したりすること）は禁止されていますが、端末からのシグナルは引き続き受け入れられます。PATHLD_LIBRARY_PATH
このsetuid機能は多くの場合非常に便利ですが、慎重に設計されていない実行可能プログラムに属性を割り当てると、不適切な使用によりセキュリティリスクが発生する可能性があります[ 2 ]。潜在的なセキュリティ上の問題のため[ 4 ] 、多くのオペレーティングシステムは、実行可能シェルスクリプトに適用された場合にこの属性を無視します[ 5 ]。setuidsetuid
実行ファイルが存在するため、Unix では非ルートユーザーがシステムコールを利用できないsetuid理由が説明できます。詳細については、制限事項を参照してください。chrootchroot
ディレクトリのアクセス許可を設定するとsetgid、そのディレクトリ内に作成されたファイルとサブディレクトリは、ファイル作成プロセスのプライマリグループではなく、設定したグループの所有権を継承します。作成されたサブディレクトリもこのsetgidビットを継承します。このポリシーは作成時にのみ適用されるため、将来にのみ有効です。setgidビットが適用された時点で既に存在するディレクトリやファイル、およびビットが設定されたディレクトリに移動されたディレクトリやファイルは影響を受けません。
これにより、ユーザーグループは明示的にアクセス許可を設定することなくファイルを操作できるようになりますが、既存のファイルのアクセス許可が暗黙的に変更されないというセキュリティモデルの前提によって制限されます。
これは通常、 BSDから派生したほとんどのシステムでは必要ありません。なぜなら、デフォルトではディレクトリは実際の値に関係なく、そのビットが常に設定されているかのように扱われるからですsetgid。[ 6 ]
FreeBSDでは、suiddirオプションでマウントされたUFSsetuidファイルシステム上のディレクトリにビットを設定すると、そのディレクトリ内に作成されたファイルとサブディレクトリは、ファイル作成プロセスのユーザー ID ではなく、そのディレクトリの所有権を継承します。[ 7 ]
これらのビットが設定されている実行ファイルは、バッファオーバーランやパスインジェクションsetuidなどのセキュリティ脆弱性を回避するために、慎重に設計および実装する必要があります。脆弱なアプリケーションに対するバッファオーバーラン攻撃が成功すると、攻撃者は悪用されたプロセスの権限で任意のコードを実行できるようになります。脆弱なプロセスがこのビットを使用してとして実行されている場合root、コードはroot権限で実行され、事実上、脆弱なプロセスが実行されているシステムへのrootアクセス権を攻撃者に与えてしまいます。
setuidまたはプロセスの場合、特に重要なのはプロセスの環境setgidです。環境が特権プロセスによって適切にサニタイズされていない場合、その動作は、それを開始した非特権プロセスによって変更される可能性があります。[ 8 ]例えば、GNU libc は、信頼できない共有ライブラリからコードを実行できる環境変数を使用したエクスプロイトに対して、かつて脆弱でした。[ 9 ]setuid
このビットはデニス・リッチー[ 10 ]setuidによって発明され、Unixの最初のバージョンに含まれていました。[ 10 ]当時彼の雇用主であったベル電話研究所は、1972年に特許を申請しました。この特許は1979年に特許番号US 4135240「データファイルの内容の保護」として付与され、同年パブリックドメインに公開されました。 [ 11 ] [ 8 ] [ 12 ]
特許は1996年に失効した。[ 13 ]
現在の Berkeley ディストリビューション (4.3BSD-tahoe) では、setuid/gid シェルスクリプトは許可されていません。
&Tは特許を一般に譲渡し、誰でもその技術を使用できるようにした。
1973: ATT は何とか setuid ビットの特許を取得し、それがハードウェアであると主張した。この特許は 1979 年にパブリックドメインに譲渡された。