多くのシステムでは、root ユーザーまたは superuser がシステムの完全な制御権を持っています。しかし UNIX ベース アプリケーション用サブシステム (SUA) は、root ユーザーを認識しません。POSIX (Portable Operating System Interface) 標準が開発された際、root ユーザーの概念は管理上の問題と見なされていました。POSIX 標準では、root ユーザーの代わりに、いくつかの操作について適切な特権が定義されています。
このトピックの内容
setuid と setgid
setuid と setgid は、プログラムを起動するときに、起動操作を行うユーザーのものとは異なるセキュリティ プリンシパルの特性を一部獲得できるようにするメカニズムです。プログラムは、これらの要素を、起動したユーザーのものと、他のセキュリティ プリンシパルのものとの間で入れ替えることができます。
適切な特権は、これとは異なります。setuid と setgid は "あなたは何者か" という問いに対するアプリケーションの回答を制御するメカニズムですが、適切な特権とは "あなたは何ができるか" という問いに対する答えです。
UNIX ベース アプリケーション用サブシステムと ID
一般的な UNIX 環境では、すべての特権が与えられるユーザーは 1 人です。それは uid == 0 のユーザーであり、一般的には root と呼ばれます。UNIX ベース アプリケーション用サブシステムでは、特定のシステムでサポートされるすべての特権が、そのシステムの Administrators グループまたは Domain Administrators グループに属するメンバー ユーザーに与えられます。管理者としてログオンする必要はありません。Administrators グループまたは Domain Administrators グループのメンバーシップを持つすべてのユーザーは root 特権を持ちます。POSIX または UNIX で定義されている特権の中には、SUA では使用できないものもあります。つまり、どのユーザーにも与えられない特権が存在します。
通常、各種の操作を行う際には適切な特権が必要です。このような操作には、ファイル システムへのアクセス、他のプロセスへの信号の送信 (プロセス制御)、プロセスが特定の操作を実行する能力を変更するための、プロセスに対して有効なユーザー ID (UID) またはグループ ID (GID) の変更などが含まれます。
POSIX 標準によると、ファイルに設定されるアクセス許可には、UID を設定するビット (setuid) と GID を設定するビット (setgid) が含まれています。この一方または両方のビットが設定されたファイルを、あるプロセスが実行すると、そのプロセスは当該ファイルの UID または GID を獲得します。このメカニズムを慎重に使用すると、特権を持たないユーザーに、ファイルの所有者またはグループが持つ上位の特権を与えてプログラムを実行させることができます。しかし誤って使用すると、特権を持たないユーザーでも、管理者以外が実行してはならない操作を実行できるようになり、セキュリティ上のリスクが生じることがあります。このため、SUA の既定ではこのメカニズムをサポートしていません。setuid または setgid ビットがセットされたファイルをユーザーが実行しようとした場合、SUA 上では実行できず、代わりにエラー コード ENOSETUID が返されます。
UNIX ベース アプリケーション用サブシステムでの setuid のセットアップに関する考慮事項
標準の POSIX 動作を必要とするアプリケーションを使用しなければならない場合は、setuid または setgid ビットがセットされたファイルを実行できるように SUA を構成できます。そのように構成した場合、setuid または setgid ビットがセットされたファイルをプロセスが実行すると、SUA は、当該ファイルの所有者またはグループに割り当てられた特権を持つローカル セキュリティ トークンを当該プロセス用に構築します。トークンはローカルであるため、ネットワーク上の他のコンピューターからは認識されません。このため、たとえばファイルが Domain Administrators グループのメンバーによって所有されている場合でも、プロセスは、Microsoft® Windows® ネットワークを通じてドメイン内の他のコンピューターへの信頼されるアクセスを持つことはありません。特権は、プロセスが実行されるコンピューター上でのみ有効になります。
たとえば、Domain Administrators グループのメンバーが所有する、setuid ビットがセットされたプログラム ファイルをプロセスが実行したとします。プログラムがドメイン ユーザーのパスワードを変更しようとすると、プロセスのセキュリティ トークンがローカルであるために、ドメイン内の他のシステムによって認識されず、変更の試みは失敗します。しかし、プログラムがローカル ユーザーのパスワードを変更しようとした場合は成功します。これは、ファイルの所有者が、一般にローカル コンピューターの Administrators グループに属する、Domain Administrators グループのメンバーであるためです。setuid または setgid ビットが設定されたファイルを実行できるように SUA を構成する方法の詳細については、UNIX ベース アプリケーションのユーティリティおよびソフトウェア開発キット (SDK) ダウンロード パッケージに付属するヘルプ ファイルを参照してください。
setuid(2)、setgid(2)、および chroot(2) の各関数を使用するプロセスは、システム アカウント、ローカル ドメインの管理者アカウント、または主要ドメインの管理者アカウントにマップし戻される実効 UID を持っている必要があります。ローカル管理者アカウントは、UID または GID を、同じドメイン内の他の ID にのみ変更することができます。
chown(1)、chmod(1)、および chgrp(1) に関しては、別のユーザーまたはグループが所有するファイルに対する make 操作や、別のユーザーが所有するファイルに対するアクセス許可の変更操作を実行するには、アカウントが Windows の SE_BACKUP および SE_RESTORE 特権を持っている必要があります。これらのアクセス許可は、通常、administrator および backup operator アカウントに割り当てられています。