次の方法で共有

Windows 整合性メカニズムの設計

  • [アーティクル]

Windows 整合性メカニズムは、カーネルのセキュリティ参照モニターに基づく Windows セキュリティ アーキテクチャの拡張機能です。 セキュリティ参照モニターは、セキュリティ アクセス トークン内のユーザー SID とグループ SID を、オブジェクトのセキュリティ記述子の ACL に付与されたアクセス許可と比較することで、アクセス制御を適用します。 整合性メカニズムは、セキュリティ アクセス トークンに整合性レベルを追加し、セキュリティ記述子のシステム ACL (SACL) に必須のラベル アクセス制御エントリを追加します。

整合性メカニズムの主な部分は次のとおりです。

  • 定義済みの整合性レベルとその表現。
  • アクセス許可を制限する整合性ポリシー。
  • セキュリティ アクセス トークンに割り当てられた整合性レベル。
  • 必須ラベル アクセス制御エントリ。
  • オブジェクトに割り当てられた必須ラベル。
  • AccessCheck API とカーネル モード SeAccessCheck API 内の整合性の制限。

これらの各部分について、以下で詳しく説明します。 Windows 整合性メカニズムは、他のセキュリティ ポリシー オプションとは無関係に、常に有効です。 アクセス制御チェックと同様に、整合性レベルのチェックは省略可能ではありません。 整合性レベルのチェックを無効にするセキュリティ ポリシー オプションはありません。 整合性メカニズムでは UAC がサポートされていますが、セキュリティ グループ ポリシーによって UAC が無効になっている場合、整合性メカニズムは有効なままです。

整合性レベル

Windows では、SID を使用して整合性レベルを定義します。 SID を使用して整合性レベルを表す場合、コードの変更を必要とせずに、整合性メカニズムを既存のセキュリティ データ構造に簡単に統合できます。 整合性レベル SID の形式は、S-1-16-xxxx です。 表 1 に、整合性レベル SID のコンポーネントを示します。

表 1 整合性レベルの SID 識別子機関の値

値 説明

16

必須ラベル機関 (SECURITY_MANDATORY_LABEL_AUTHORITY) を表します。

xxxx

整合性レベルである相対識別子 (RID) フィールドを表します。 RID は、整合性レベルを表す 16 進値です。

Windows Vista には、対応する 4 つの値を持つ 4 つの主要な整合性レベルがあります。 値が小さい場合は、整合性レベルが低いか、信頼度が低くなります。 これらの値は、ヘッダー ファイル winnt.h で定義されます。 表 2 に、定義された整合性レベルとそれに対応する値を示します。

表 2 定義された整合性レベルと対応する値

値 説明 Symbol

0x0000

信頼されていないレベル

SECURITY_MANDATORY_UNTRUSTED_RID

0x1000

整合性レベルが低い

SECURITY_MANDATORY_LOW_RID

0x2000

中程度の整合性レベル

SECURITY_MANDATORY_MEDIUM_RID

0x3000

高い整合性レベル

SECURITY_MANDATORY_HIGH_RID

0x4000

システムの整合性レベル

SECURITY_MANDATORY_SYSTEM_RID

中程度の整合性レベル SID の例として、S-1-16-8192 という文字列があります。 RID 値 8192 は、0x2000に相当する 10 進数です。

RID は、将来の追加レベルの定義を可能にするために、0x1000の間隔で区切ります。 また、分離により、特定のシステム設計目標を満たすために、中程度よりもわずかに高いプロセスに整合性レベルを割り当てることもできます。

定義された整合性レベル SID には、それらに関連付けられた文字列名の値があります。 API LookupAccountSID を 使用すると、整合性レベル SID ごとに文字列名が返されます。 表 3 に、整合性レベルの文字列名を示します。

表 3 整合性レベルの文字列名

整合性レベル SID 名前

S-1-16-4096

必須ラベル\低必須レベル

S-1-16-8192

必須ラベル\中程度の必須レベル

S-1-16-12288

必須ラベル\高い必須レベル

S-1-16-16384

必須ラベル\システム必須レベル

整合性レベルは、セキュリティ記述子定義言語 (SDDL) の SID 文字列としても定義されます。 SDDL では、ConvertSecurityDescriptorToStringSecurityDescriptor 関数と ConvertStringSecurityDescriptorToSecurityDescriptor 関数が、セキュリティ記述子をテキスト文字列として記述するために使用する文字列形式を定義します。 言語では、セキュリティ記述子のコンポーネント内の情報を記述するための文字列要素も定義されます。 SDDL を使用して整合性レベルを定義すると、オブジェクトの作成時にオブジェクトの整合性レベルを定義するのに便利です。 整合性レベルの SID 文字列の詳細については、「 Windows 整合性メカニズム リソース」を参照してください。 必須ラベルの SDDL サポートについては、「 付録 A: 必須ラベルの SDDL」を参照してください。

Windows Vista では、セキュリティ アクセス トークンの整合性レベル SID を使用してサブジェクトの整合性レベルを表し、セキュリティ記述子の必須ラベル ACE の整合性レベル SID を使用してオブジェクトの整合性レベルを表します。

整合性ポリシー

Windows 整合性メカニズムでは、単純なポリシーを使用して、オブジェクトの必須ラベルを使用して、整合性の低いサブジェクトに使用できるアクセス レベルを制限する方法を決定します。 つまり、ポリシーは、整合性レベルの低いオブジェクトが高整合性レベルのオブジェクトに対して持つことが許可されるアクセスの種類を制限します。 表 4 に、2 つのポリシー カテゴリを示します。

表 4 整合性ポリシーのカテゴリ

カテゴリ 説明

アクセス トークンの必須ポリシー

アクセス トークンで を設定し、アクセス トークンで表されるサブジェクトに必須ポリシーがどのように適用されるかを決定します。

必須ラベル ポリシー

オブジェクトに対して必須ラベル ACE (後述) を設定し、オブジェクトへのアクセスを制限する方法を決定します。

整合性ポリシーは、セキュリティ保護可能なオブジェクトに対するアクセス許可を評価するときに、必須ポリシー チェックが実行されるときに使用されます。 ポリシーは、整合性レベル間でアクセス権を制限する方法を決定します。

必須アクセス トークン ポリシー

表 5 に、Windows Vista で定義されている必須のアクセス トークン ポリシーを示します。

表 5 Windows Vista の必須アクセス トークン ポリシー

ポリシー 説明

TOKEN_MANDATORY_NO_WRITE_UP

すべてのアクセス トークンに割り当てられる既定のポリシー。 ポリシーは、このサブジェクトによる書き込みアクセスを、より高い整合性レベルのオブジェクトに制限します。

TOKEN_MANDATORY_NEW_PROCESS_MIN

整合性レベルを子プロセスに割り当てる動作を制御します。 通常、子プロセスは、親プロセス アクセス トークンが子に割り当てられると、親プロセスの整合性レベルを継承します。 NEW_PROCESS_MIN ポリシーでは、子プロセスの整合性レベルは、親アクセス トークンの最小整合性レベル、または新しいプロセスの実行可能ファイルのオブジェクトの整合性レベルになります。 このポリシーは、すべてのアクセス トークンで既定で設定されます。

NEW_PROCESS_MIN ポリシーは、例で説明できます。 lowcalc.exeと呼ばれる実行可能プログラムがあるとします。 プログラム ファイルには、低整合性ラベルが割り当てられます。 コマンド プロンプトから、ユーザーは lowcalc.exeを実行します。 親プロセスcmd.exeは、中程度の整合性レベルで実行されています。 イメージ ファイルlowcalc.exeは整合性ラベルが低いため、NEW_PROCESS_MIN ポリシーは新しいプロセスの整合性レベル (低calc) を低に設定します。 これは、以下の「 低整合性レベルで実行するアプリケーションの設計」セクションの例に示されています。

必須ラベル ポリシー

必須ラベル ポリシーは、必須ラベル アクセス制御エントリの [マスク ] フィールドでフラグ (ビット) として定義されます。 これらのポリシー フラグは、整合性の低いサブジェクトに適用されるアクセス許可に対する制限を決定します。 表 6 に、Windows Vista で定義されている必須ラベル ポリシーを示します。

表 6 Windows Vista の必須ラベル ポリシー

ポリシー 説明

SYSTEM_MANDATORY_POLICY_NO_WRITE_UP

すべてのオブジェクトの必須ラベルに対する既定のポリシー。 フラグは、NO_WRITE_UPアクセス トークン ポリシーと同じです。 ポリシーは、整合性レベルが低いサブジェクトによってオブジェクトへの書き込みアクセスを制限します。

SYSTEM_MANDATORY_POLICY_NO_READ_UP

整合性レベルが低いサブジェクトによって、オブジェクトへの読み取りアクセスを制限します。 ポリシーは、たとえば、プロセスの仮想メモリ アドレス空間への読み取りアクセスを制限するために使用されます。

SYSTEM_MANDATORY_POLICY_NO_EXECUTE_UP

整合性レベルが低いサブジェクトによって、オブジェクトへの実行アクセスを制限します。 このポリシーは、たとえば、COM クラスの起動アクティブ化アクセス許可を、整合性の低いサブジェクトによって制限するために使用されます。

これらの定義されたポリシーは、Windows Vista の設計目標を満たしています。 整合性メカニズムのアーキテクチャでは、サブジェクトとオブジェクト間のアクセス許可を異なる整合性レベルで制御する追加のポリシー オプションを定義することで、将来の拡張が可能になります。

整合性ポリシーを汎用権限にマップする方法

必須ポリシー チェックは、AccessCheck セキュリティ機能の一部として行われます。 AccessCheck (およびカーネル モードの SeAccessCheck) には、関数パラメーターの 1 つとして GENERIC_MAPPING 構造体があります。 呼び出し元によって提供されるジェネリック マッピングは、オブジェクト固有のアクセス権を、読み取り、書き込み、実行のジェネリック カテゴリにマップします。 必須ラベル ポリシーでは、汎用カテゴリに基づいて、許可されたアクセスに対する制限が実装されます。 特定のオブジェクトの種類の場合、GENERIC_MAPPINGは、特定のアクセス権が禁止されている必須ポリシーチェックに通信します。

AccessCheck の呼び出しに渡されるGENERIC_MAPPING構造体がすべてゼロ (0) の場合、ジェネリック マッピングは未定義です。 汎用マッピングが未定義の場合、必須ポリシーチェックは、整合性の低いサブジェクトによってすべてのアクセス権を制限します。 プライベート オブジェクト セキュリティに AccessCheck を使用し、すべてのゼロのGENERIC_MAPPING構造を渡すリソース マネージャーには 、アクセス拒否エラーが 表示されます。 必須ポリシーで適用される汎用アクセス権にオブジェクトの種類固有のアクセス権をマップするには、リソース マネージャー アプリケーションに対するコード変更が必要です。

アクセス トークンに整合性レベルを割り当てる方法

セキュリティ アクセス トークンは、カーネルが使用する内部データ構造です。 セキュリティ アクセス トークンには、特権、グループ メンバーシップ、およびその他のセキュリティ関連の詳細に対応するさまざまな情報値が含まれています。 アクセス トークンの初期化は、ユーザーが対話形式で Windows にログオンするとき、またはネットワーク認証が行われるときに発生します。 アクセス トークンが初期化されると、他の値に加えて、ユーザーの SID、グループ SID、および特権が追加されます。 Windows Vista では、アクセス トークンが初期化されるときに、アクセス トークンの整合性レベルが割り当てられます。

カーネルは、すべてのプロセスとスレッドにアクセス トークンを割り当てます。 プロセスのプライマリ アクセス トークンには、そのプロセスに関連付けられている整合性レベルが含まれています。 Windows 整合性メカニズムでは、プロセスの整合性レベルをサブジェクト整合性レベルと呼びます。 アプリケーションのアクセス トークンに中整合性 SID が含まれている場合、アプリケーション プロセスは中整合性レベルで実行されます。 同じユーザー アカウントで実行されている複数のアプリケーション プロセスに、同じプライマリ アクセス トークンが割り当てられます。 これは、各アプリケーションに同じ整合性レベルが割り当てられる方法です。

整合性レベルは、TOKEN_GROUPS構造に存在する特定のグループ SID に基づいてアクセス トークンに割り当てられます。 Windows カーネルは、特定の組み込みユーザーまたはグループ アカウントに基づいて整合性レベルを割り当てます。 Windows Vista は、ローカル システム アカウント SID がシステムの整合性レベルを示すアクセス トークンを割り当て、ローカル管理者グループ SID が存在するアクセス トークンには高の整合性レベルが割り当てられ、標準ユーザー アカウントのアクセス トークンには中の整合性レベルが割り当てられます。

表 7 は、特定の SID の存在に基づいて、アクセス トークンへの整合性レベルの割り当てを示しています。

表 7 特定の SID にリンクされている整合性レベル

アクセス トークン内の SID 割り当てられた整合性レベル

LocalSystem

システム

LocalService

システム

NetworkService

システム

管理者

高

Backup Operators

高

Network Configuration Operators

高

Cryptographic Operators

高

Authenticated Users

Medium

Everyone (World)

低

匿名

信頼されていません

整合性レベルは、さまざまなレベルのアクセスで実行されているアプリケーションに対して、さまざまなレベルの信頼性を定義します。 Windows Vista のほとんどのアプリケーションは、標準のユーザー レベルのアクセス権で中程度の整合性レベルで実行されます。 中程度の整合性レベルのアプリケーションでは、他のアプリケーションやデータとの対話方法に関する制限は中程度の整合性レベルでは発生しません。 管理者権限を必要とする特定のタスクまたはアプリケーションは、高い整合性レベルで実行されます。 システム サービスは、既定のデスクトップと対話する機能に制限があり、多くの場合、強力なシステム特権で実行されるため、システム整合性レベルで実行されます。 保護モードのインターネット エクスプローラーなど、可能な限り少ない権限で実行するように設計されたいくつかのアプリケーションは、整合性レベルが低い状態で実行できます。

特定の管理 Windows 特権は、少なくとも高い整合性レベルでのみアクセス トークンに割り当てることができます。 アクセス トークンの整合性レベルが高未満の場合、特定の管理特権は許可されず、アクセス トークンから削除されます。 高い整合性レベルに関連付けられている管理特権は次のとおりです。

  • SE_CREATE_TOKEN_PRIVILEGE
  • SE_TCB_PRIVILEGE
  • SE_TAKE_OWNERSHIP_PRIVILEGE
  • SE_BACKUP_PRIVILEGE
  • SE_RESTORE_PRIVILEGE
  • SE_DEBUG_PRIVILEGE
  • SE_IMPERSONATE_PRIVILEGE
  • SE_RELABEL_PRIVILEGE
  • SE_LOAD_DRIVER_PRIVILEGE

アプリケーションは、子プロセスを作成するときに、重複するアクセス トークンに低整合性レベルを割り当てることができます。 実行可能プログラム イメージ ファイルに低い必須ラベルがある場合、Windows は整合性レベルが低いアプリケーション プロセスを実行する可能性があります。 これらの機能については、この記事で後述します。

アクセス トークンの整合性レベルを取得する方法

整合性レベルは、TOKEN_GROUPS フィールドを使用してアクセス トークンに格納されます。 TOKEN_GROUPS構造体は、そのユーザー アカウントのグループ メンバーシップを識別する SID と属性の一覧です。 アクセス トークンの整合性レベルは、SID 属性を使用してグループ リストでも識別されます。 SID_AND_ATTRIBUTES構造体には整合性レベル SID が含まれており、SE_GROUP_INTEGRITY属性とSE_GROUP_INTEGRITY_ENABLED属性を使用して整合性レベルが識別されます。

GetTokenInformation API を使用して、アクセス トークンの整合性レベルをアクセス トークンから取得できます。 GetTokenInformation には、取得するアクセス トークン情報クラスを示すパラメーターがあります。 TOKEN_INFORMATION_CLASS パラメーターには、整合性レベル TokenIntegrityLevel の定義された値があります。 返されるデータ構造は、TOKEN_MANDATORY_LABEL型です。

プロセスの整合性レベルを決定するには

  1. プロセスのアクセス トークンへのハンドルを開きます。

  2. アクセス トークンの整合性レベルを取得します。

  3. 整合性レベル SID をシステム定義の整合性レベル RID と比較します。

アクセス トークンの整合性レベルを取得するためのコード例を付録 D に示します。

アクセス トークンの整合性レベルを表示する方法

プロセスのセキュリティ アクセス トークンの整合性レベルは、プロセスのセキュリティの詳細を公開するツール (SysInternals.com からプロセス エクスプローラーなど) を使用して表示できます。 次の図は、ビューに [整合性レベル] 列が追加された [プロセス エクスプローラー] の表示を示しています (右側)。

図 1 プロセス エクスプローラーの整合性レベル

explorer.exeなどの特定のプロセスのセキュリティ プロパティを確認すると、プロセス エクスプローラーは、プロセスのセキュリティ アクセス トークンで定義されているグループの一覧に整合性レベルを示します。 次の図は、プロセスのアクセス トークンに割り当てられている必須ラベル/中の必須レベルを示explorer.exe。

図 2 中間整合性レベル プロセスとしてのExplorer.exe

アクセス トークンの整合性レベルを設定する方法

通常、アプリケーションはプロセスの整合性レベルの値を変更する必要はありません。 通常、アプリケーションはセキュリティ アクセス トークンのどの値にも変更を加える必要はありません。 ただし、状況によっては、異なる整合性レベルでローカル クライアントをサポートするサービスが、より低い整合性レベルでタスクを実行することを選択する場合があります。 偽装は、サービス スレッドが低い整合性レベルで実行されている可能性がある 1 つの方法です。 サービス スレッドがローカル クライアントを偽装すると、偽装スレッドにはクライアントのセキュリティ コンテキストがあり、クライアントが同じローカル コンピューターで実行されている場合は、クライアントの整合性レベルが含まれます。

一連のファイルとレジストリ キーの作成など、アプリケーションで操作を実行できるもう 1 つの方法は、現在のスレッド アクセス トークンに TokenIntegrityLevel を設定することです。 新しい整合性レベルは、プロセスのプライマリ アクセス トークンの整合性レベルより高くすることはできません。

スレッドでアクセス トークンの整合性レベルの値を設定するには

  1. OpenThreadToken を呼び出して、アクセス トークンへのハンドルを取得します。

  2. 現在のスレッドの整合性レベルを保存するには、TokenIntegrityLevel のTOKEN_INFORMATION_CLASSパラメーター値を指定して GetTokenInformation を呼び出します。

  3. TokenIntegrityLevel のTOKEN_INFORMATION_CLASSパラメーター値を使用して SetTokenInformation を呼び出します。

異なる整合性レベルのスレッド間のプロセス アドレス空間内にセキュリティ境界がないため、アプリケーション デザイナーは、整合性の高いプロセスで実行される整合性が低いスレッドでコードを実行する潜在的なセキュリティ リスクを考慮する必要があります。 ほとんどのアプリケーションでは、整合性の低いタスクを実行するために、整合性レベルが低い別のプロセスを作成する方が簡単です。

TokenIntegrityLevel を設定し、より低い整合性レベルでプロセスを作成する方法の例については、「アクセス トークンの整合性レベルを設定する方法」を参照してください。

必須ラベル ACE

Windows 整合性メカニズムでは、新しい ACE の種類 (システム必須ラベル ACE) が定義されます。 必須ラベル ACE は、オブジェクトのセキュリティ記述子内のオブジェクトの必須ラベルを表すために使用されます。 必須ラベルには、整合性レベルと関連付けられた整合性ポリシーが含まれています。 必須ラベル ACE は、セキュリティ記述子のシステム ACL (SACL) でのみ使用されます。 SACL は、随意 ACL (DACL) とは別のセキュリティ記述子のフィールドです。

図 3 セキュリティ記述子フィールド

随意 ACL には、オブジェクトに対するユーザーとグループのアクセス許可が含まれています。 どのユーザーまたはグループでも、WRITE_DACオブジェクト アクセス許可を使用して DACL を更新できます。 随意 ACL は、さまざまなユーザーによって、より頻繁に更新できます。 整合性メカニズムの設計目標の 1 つは、必須ラベルがオブジェクトに適用された後に、セキュリティ システムがオブジェクトでラベルを維持する必要があるということです。 ACL を管理するように設計されたアプリケーションにほとんど、またはまったく影響を与えずに、オブジェクト セキュリティ記述子に適切な必須ラベルを適用するには、システム ACL に必須ラベルを配置します。このラベルは、主にセキュリティ システムの制御下にあります。 必須ラベルは、SACL のシステム監査エントリとは論理的に分離されています。 SACL のシステム監査エントリの前または後に必須ラベルを付ける必要はありません。

必須ラベル ACE は、ACE ヘッダー、アクセス マスク、SID が含まれているという点で、アクセスが許可されている ACE に似ています。 必須ラベル ACE の SID 部分には、整合性レベル SID が含まれています。 表 8 に ACE ヘッダーのフィールドを示します。

表 8 ACE ヘッダーに含まれるフィールド

ACE ヘッダー フィールド 値

AceType

SYSTEM_MANDATORY_LABEL_ACE_TYPE

AceFlags

必須ラベル ACE 型の継承を定義するコントロール フラグ

AceSize

必須ラベル ACE のサイズ

必須ラベル ACE には 、マスク フィールドが含まれています。 マスクは、整合性レベルが低いプロセス (またはサブジェクト) に適用されるアクセス許可の制限を決定する必須ポリシーを定義するために使用されます。 Windows Vista で広く使用されているポリシーの例として、NO_WRITE_UP ポリシーがあります。 必須ラベル ACE マスクのNO_WRITE_UPポリシー フラグは、オブジェクトの必須ラベルの整合性レベル SID よりも (アクセス トークン内の) 整合性レベルが低いサブジェクトが、オブジェクトへの汎用書き込みアクセスを取得することを制限することを意味します。

オブジェクトには有効な必須ラベルが 1 つだけ存在します。 セキュリティ記述子が SACL で複数の必須ラベルを取得する場合、SACL の最初の必須ラベル ACE はオブジェクトの有効なラベルです。

必須ラベル ACE の詳細については、「 Windows 整合性メカニズム リソース」を参照してください。

必須ラベル ACE の読み取り

Windows Vista では、セキュリティ関数 GetSecurityInfo を使用して、オブジェクトから必須ラベル情報を読み取ります。 GetSecurityInfo は、オブジェクトから所有者、グループ、DACL、または SACL の情報を取得します。 GetSecurityInfo の SECURITY_INFORMATION パラメーターによって、返されるセキュリティ記述子の部分が決まります。 Windows Vista では、SACL から必須ラベル ACE を返すために使用される新しいセキュリティ情報の値LABEL_SECURITY_INFORMATIONを定義します。 GetSecurityInfo の呼び出しでSACL_SECURITY_INFORMATIONが指定されている場合、SACL のシステム監査 ACE のみが返され、必須ラベル ACE は返されません。

オブジェクトの必須ラベル ACE を読み取るために必要なアクセス許可は、READ_CONTROL標準アクセス権です。 通常、SACL で情報を取得または設定するには、ACCESS_SYSTEM_SECURITYアクセス権が必要です。 ACCESS_SYSTEM_SECURITYは、アクセス トークンでSE_SECURITY_NAME特権が有効になっている場合にのみ付与されます。 SACL から必須ラベルを読み取る場合、SE_SECURITY_NAME特権やACCESS_SYSTEM_SECURITYアクセス権は必要ありません。

必須ラベル ACE の設定

Windows Vista では、セキュリティ関数 SetSecurityInfo を使用して、オブジェクトの必須ラベル情報を変更します。 オブジェクトの必須ラベルは、オブジェクトの作成時にセキュリティ サブシステムによって設定されます。 セキュリティ記述子の必須ラベルを変更するには、SetSecurityInfo の SECURITY_INFORMATION パラメーターにLABEL_SECURITY_INFORMATIONを含める必要があります。

オブジェクトの作成時に割り当てられる必須ラベルは、通常、オブジェクトの正しい整合性レベルであり、必須ラベルを変更する必要はありません。 ただし、アプリケーションが異なる整合性レベルで複数のクライアント プロセスをサポートするように設計されている場合、オブジェクトの整合性レベルを変更するためのアプリケーション設計要件がある場合があります。

セキュリティ記述子の SACL で必須ラベル ACE を変更するために必要なアクセス許可がWRITE_OWNER。 SACL に必須ラベルを書き込むには、SE_SECURITY_NAME特権やACCESS_SYSTEM_SECURITYアクセス権は必要ありません。 必須ラベルの整合性レベルは、サブジェクトの整合性レベル以下の値に設定できます。

最も一般的な変更は、オブジェクトの整合性レベルを下げて、整合性の低いアプリケーション プロセスで変更アクセスを許可することです。 たとえば、中程度の整合性レベルのアプリケーションは、整合性レベルが低い別のアプリケーション プロセスと同期する必要があります。 中整合性プロセスでは、名前付きミューテックス オブジェクトを作成し、低いレベルで必須ラベルを割り当てて、整合性の低いプロセスでミューテックスを開いてイベントを通知できます。

再ラベル付け特権

Windows 整合性メカニズムでは、新しい Windows セキュリティ特権 (SE_RELABEL_NAME) が定義されます。 セキュリティ アクセス トークンで有効にすると、ラベルの再作成セキュリティ特権を使用すると、サブジェクトは、サブジェクトのアクセス トークンの整合性レベルよりも高い整合性レベルにオブジェクトの必須ラベルを設定できます。 Windows Vista の既定のセキュリティ ポリシーでは、この特権はどのユーザーまたはグループにも割り当てられません。 この特権は、高い整合性レベルで実行されている管理者プロセスが、システムの整合性レベルでオブジェクトの必須ラベルを変更または割り当てる必要があるシナリオに対処するように設計されています。 Windows Vista には、再ラベル付け特権を必要とするタスクや使用するタスクはありません。

Windows でオブジェクトに必須ラベルを割り当てる方法

Windows では、オブジェクト セキュリティ記述子の作成時に、セキュリティ保護可能なオブジェクトに必須ラベルが割り当てられます。 新しいオブジェクトの整合性レベルは、次の 3 つの方法のいずれかで割り当てられます。

  • セキュリティ サブシステムは、オブジェクトに対してセキュリティ記述子が作成されるときに、オブジェクトに必須ラベルを割り当てます。
  • 作成プロセスでは、CreateFile などの関数を使用してオブジェクトを作成するときに、明示的な必須ラベルをセキュリティ属性として指定します。
  • 親コンテナーは、コンテナー内に作成された子オブジェクトに適用される継承可能な必須ラベル ACE を定義します。

オブジェクトの整合性レベルがどのように割り当てられているかを理解する最も簡単な方法は、すべてのオブジェクトに、作成プロセス (またはスレッド) のサブジェクト整合性レベルと同じ整合性レベルの必須ラベルが割り当てられていることを前提とすることです。 ただし、オブジェクトの種類とサブジェクトの整合性レベルに基づく一般的な考え方には例外があります。 例外は、UAC などのさまざまなセキュリティ ポリシーが有効または無効になっている場合に、一貫性のあるユーザー エクスペリエンスのために他のシステム要件をサポートするために必要な設計上の選択の結果です。

必須ラベルは、セキュリティ記述子に基づいてアクセス制御を持つすべてのセキュリティ保護可能なオブジェクトに適用できます。 セキュリティ保護可能なオブジェクトには、プロセス オブジェクトとスレッド オブジェクト、名前付きオブジェクト、ファイルやレジストリ キーなどの永続オブジェクトなど、さまざまな種類があります。 Windows Vista では、オブジェクトの作成時にすべてのオブジェクトの種類に明示的な必須ラベルが割り当てられるわけではありません。 オブジェクトの作成時にセキュリティ サブシステムが必須ラベルを割り当てるオブジェクトの種類は次のとおりです。

  • Process
  • スレッド
  • アクセス トークン
  • ジョブ

他のすべてのオブジェクト型には、暗黙的な既定値または継承された必須ラベルがあります。 アクセス トークンの初期化中に、対話型ログオン中に作成されるセキュリティ アクセス トークンに整合性レベルが割り当てられることを思い出してください。 ユーザー ログオンの代わりに起動される最初のプロセスは、シェル プロセスを開始するuserinit.exeexplorer.exe。 Userinit.exeは、CreateProcessAsUser の呼び出しを使用し、対話型ログオン ユーザーのアクセス トークンを渡すシステム サービス (Winlogon) によって開始されます。

CreateProcessAsUser は、プロセス オブジェクトと初期スレッドなどを作成します。 プロセス オブジェクトが作成されると、そのプロセスのセキュリティ記述子には、プライマリ アクセス トークンとして割り当てられたアクセス トークンから新しいプロセスへの整合性レベルが割り当てられます。 userinit.exe CreateProcess を呼び出してシェルを起動すると、explorer.exeのプロセス オブジェクトが初期化されます。 プロセス オブジェクトには、セキュリティ記述子とプライマリ アクセス トークンが含まれています。 explorer.exe プロセスの必須ラベルは、作成プロセスの整合性レベル (userinit.exe) に設定されます。これは中です。 explorer.exeのプライマリ アクセス トークンは、作成する親プロセスから継承され、userinit.exeされ、整合性レベルは medium です。 explorer.exe プロセスで新しいスレッドが作成されると、スレッド オブジェクトにセキュリティ記述子が与えられ、セキュリティ サブシステムは、作成プロセスの整合性レベルに基づいて整合性レベルをスレッド オブジェクトに割り当てます。 explorer.exe プロセス内のスレッド オブジェクトには、作成プロセスのプライマリ アクセス トークンの整合性レベルである medium の整合性レベルが割り当てられます。

注意

アクセス トークン オブジェクトは、独自のセキュリティ記述子を持つセキュリティ保護可能なオブジェクトです。 トークンのセキュリティ記述子は、OpenProcessToken 関数または OpenThreadToken 関数中に許可されるアクセスを決定するために使用されます。 アクセス トークン オブジェクトには、アクセス トークン オブジェクトのセキュリティ記述子に必須のラベルがあります。 アクセス トークンには、サブジェクトの整合性レベルを表すアクセス トークン グループの一覧に整合性レベル SID も含まれています。

プロセス、スレッド、トークン、およびジョブ オブジェクトに常に必須ラベルを割り当てることで、整合性メカニズムにより、整合性レベルの低い同じユーザーのプロセスがこれらのオブジェクトの種類にアクセスしたり、DLL の挿入や上位レベルのアクセス トークンの偽装などのコンテンツや動作を変更したりできなくなります。

既定の整合性レベル

すべてのオブジェクト型に、セキュリティ記述子に必須ラベル ACE が割り当てられているわけではありません。 セキュリティ記述子に必須ラベル ACE が存在する場合、これは明示的な必須ラベルと呼ばれます。 必須ラベル ACE が存在しない場合、セキュリティ サブシステムは、必須ポリシー チェック中にそのオブジェクトに対して暗黙的な既定の必須ラベルを使用します。 既定の必須ラベルは、セキュリティ保護可能なすべてのオブジェクトに中程度の整合性レベルを割り当てます。 セキュリティ記述子で必須ラベルが定義されていない場合、暗黙的な既定の必須ラベルはすべてのオブジェクト型に適用されます。

medium の既定のオブジェクト整合性レベルは、NO_WRITE_UPの既定の必須ポリシーと組み合わされ、サブジェクト整合性レベルが medium 未満のプロセスによってすべてのオブジェクトへの変更アクセスが制限されます。 既定の必須ラベルとポリシーにより、低整合性の信頼できないプロセスが、DACL で随意書き込みアクセスを許可する可能性があるシステム上のユーザーまたはシステム ファイルまたはレジストリ キーを変更できなくなります。

NTFS ファイル システム オブジェクトとレジストリ キーは、作成時に自動的にラベル付けされません。 これらのオブジェクトには、以前のバージョンの Windows から Windows Vista へのアップグレード後に必須のラベルがありません。 セキュリティ記述子を持たない非 NTFS ファイル システム (CDFS または FAT32) 上のファイルは、セキュリティ保護可能なオブジェクトではなく、整合性レベルがありません。 すべてのセキュリティ記述子には、暗黙的な必須ラベルが必要です。

サブジェクト整合性レベルが中程度以上のプロセスでは、明示的なラベルのないファイルとレジストリ キーが作成されます。 その結果、高レベルまたはシステム整合性レベルのプロセスによって作成されるファイル システム オブジェクトとレジストリ オブジェクトには、暗黙的な中レベルのラベルがあります。 必須ラベルを使用するアプリケーションでは、オブジェクトの作成時に明示的なラベルを定義できます。 ただし、Windows Vista では、既定では、ファイル システムまたはレジストリに中程度の整合性レベルより高いラベルは割り当てません。 これは、これらのオブジェクトが必ずしも整合性の低いプロセスによる変更を受け入れているという意味ではありません。 高レベルまたはシステム レベルのプロセスによって作成されたファイル システムまたはレジストリ オブジェクトの継承された (または既定の) 随意アクセス制御リストは、Administrators グループのメンバー、またはローカルのシステムまたはサービス アカウントにのみ書き込みアクセス権を付与します。

ほとんどのオブジェクト型のサブジェクトの整合性レベルに基づいて明示的な必須ラベルを割り当てる代わりに、medium の既定の暗黙的な必須ラベルを使用して必要な設計上の制約の数。 具体的な例は、ローカル セキュリティ ポリシーを使用してユーザー アカウント制御を有効または無効にする機能に基づいています。 UAC が無効になっている場合、ローカル Administrators グループのメンバーであるユーザーは、高い整合性レベルで完全な特権アクセス トークンを使用して実行されているすべてのプロセスを持ちます。 すべてのオブジェクトがサブジェクトの整合性レベルで明示的にラベル付けされている場合、ユーザーが作成するドキュメントやスプレッドシートなどのすべてのファイルに高い整合性レベルが割り当てられます。 ユーザー プロファイルの継承された DACL アクセス許可によってユーザー アクセスに対する十分なアクセス制御が提供される場合でも、高ラベルは適切に見えます。 ただし、UAC がローカル コンピューターまたはグループ ポリシーによって有効になっている場合、同じユーザーによって実行されるほとんどのプロセスには、フィルター処理されたセキュリティ アクセス トークンが中程度の整合性レベルで割り当てられます。 UAC を有効にすると、UAC が無効になったときに作成されたファイルを開くことができません。 ユーザーの高整合性ドキュメントを開こうとした中整合性アプリケーションでは、アクセス拒否エラーが発生します。

サブジェクト整合性レベルが medium の既定の整合性レベルより小さい状態でプロセスが実行されている場合、そのプロセスには、暗黙的な中程度の整合性レベルを持つすべてのオブジェクトに対するアクセス許可が制限されます。 整合性レベルが低いプロセスでは、DACL でセキュリティ プリンシパルに付与されたアクセス権に関係なく、明示的または暗黙的な整合性レベルが medium 以上のオブジェクトを変更することはできません。 したがって、サブジェクト整合性レベルが既定のレベル (中) 未満のプロセスによって作成されたすべてのオブジェクトは、セキュリティ サブシステムによって明示的にラベル付けされます。 すべてのアプリケーションは一般に中程度の整合性レベルで実行され、アプリケーションの互換性の問題は最小限であるため、Windows Vista では、整合性の低いプロセスに対するアクセス制限が可能です。 整合性が低い状態で正しく実行されるアプリケーションでは、通常、アクセスが制限された状態で正しく動作するために、特定の設計変更が必要です。 設計の変更については、以下の「 低整合性レベルで実行するアプリケーションの設計」セクションで説明します。

低サブジェクトによって作成されたオブジェクトのラベル付け

アプリケーションは、整合性レベルが低い CreateProcessAsUser 関数を使用して開始できます。 低プロセスは、次の整合性レベル情報を使用して CreateProcessAsUser によって初期化されます。

  • 新しいプロセス オブジェクトは、整合性が低い必須ラベルを含むセキュリティ記述子を使用して作成されます。
  • そのプロセス用に、および整合性の低い必須ラベルを含むセキュリティ記述子を使用して、新しいスレッド オブジェクトが作成されます。
  • プライマリ アクセス トークンが新しいプロセスに割り当てられます。 アクセス トークン オブジェクトには、必須ラベルが低いセキュリティ記述子があり、アクセス トークンには、サブジェクトの整合性レベルを表す整合性が低い SID を持つ TokenIntegrityLevel が含まれています。

整合性の低いプロセスが実行されており、スレッドを作成するとします。 スレッドを作成するには、新しいスレッド オブジェクトを作成するための書き込みアクセス用に独自のプロセス オブジェクトを開く必要があります。 プロセス オブジェクトの必須ラベルが中の場合、低いサブジェクトはプロセスを開けず、新しいスレッドを作成できません。 プロセス オブジェクトにも低整合性のラベルが付いているため、低サブジェクトは書き込みアクセス用にプロセスを開き、新しいスレッド オブジェクトを作成できます。 この例では、プロセス オブジェクト、スレッド オブジェクト、およびセキュリティ アクセス トークンの必須ラベルが同じ整合性レベルで一貫性を保つ必要がある理由を示します。

注意

これは、低い対象だけでなく、すべての整合性レベルに適用されます。

低プロセスで一時ファイルが作成されたとします。 アプリケーションは CreateFile を呼び出して新しいファイルを作成し、データを書き込み、ファイルを閉じます。 その後、低いプロセスでは、データを追加するために同じファイルを再度開く必要があります。 一時ファイルに中整合性レベルの暗黙的な既定の必須ラベルがある場合、低プロセスでは、変更アクセスのために前に作成したファイルを再度開くことができません。 整合性レベルが既定の medium レベルを下回るサブジェクトが作成するセキュリティ保護可能なオブジェクトでも、同じ問題が発生する可能性があります。 したがって、既定のレベルを下回る整合性レベルを持つサブジェクトによって作成されたすべてのセキュリティ保護可能なオブジェクトには、明示的な必須ラベルが自動的に割り当てられます。 つまり、すべてのカーネル オブジェクト、レジストリ キー、およびファイル システム オブジェクトは、サブジェクトの整合性レベルが低い場合に明示的に低いラベルが付けられます。

特定の必須ラベルを持つオブジェクトを作成する方法

ほとんどの Windows アプリケーションは、"整合性に対応する" 必要はありません。 セキュリティ サブシステムは、オブジェクトを自動的に作成し、必須ラベルを割り当てます。 ほとんどのアプリケーションは中程度の整合性レベルで実行され、既定のオブジェクトの整合性レベルは medium であるため、整合性ポリシーによって、ほとんどのアプリケーションで許可されるアクセス制御は変更されません。 ただし、サービスなどの一部のアプリケーションは、異なる整合性レベルでクライアント アプリケーションをサポートするように設計されています。 サービスはクライアントよりも高い整合性レベルで実行されており、クライアントの代わりに作成された新しいオブジェクトに、より低い整合性レベルで明示的にラベルを付ける必要がある場合があります。 オブジェクトの整合性レベルは、作成プロセスによって設定できます。 制約は、新しいオブジェクトの整合性レベルが、作成プロセスの整合性レベル以下である必要があることです。

特定の必須ラベルを持つオブジェクトを作成するには
  1. 低い必須ラベルを定義する SDDL セキュリティ記述子を作成します。次に例を示します。
    #define LOW_INTEGRITY_SDDL_SACL_W L"S:(ML;;NW;;;LW)"
  2. ConvertStringSecurityDescriptorToSecurityDescriptor を使用して、SDDL 文字列をセキュリティ記述子に変換します。
  3. 低い必須ラベルを持つセキュリティ記述子をセキュリティ属性構造に割り当てます。
  4. CreateFile などのオブジェクトを作成するための呼び出しにセキュリティ属性パラメーターを渡します。

必須ラベルの継承

Windows Vista では、NTFS ファイル システム内のファイルとディレクトリに明示的にラベルを付けません。 前述のように、セキュリティ サブシステムは、セキュリティ記述子に必須ラベルがないオブジェクトに対して、既定のレベルの medium を持つ暗黙的な必須ラベルを使用します。

アプリケーションは、低整合性レベルで実行するように設計できます。 保護モードのインターネット エクスプローラーは、低整合性で実行するように設計された Windows Vista アプリケーションの例です。 整合性が低いアプリケーションでは、一時ファイルまたはアプリケーション データを書き込むことができるファイル システム内のフォルダーが必要になる場合があります。 保護モードのインターネット エクスプローラーの場合は、ユーザーのプロファイルの一時インターネット ファイル フォルダーが使用されます。 低いアプリケーションをファイル システム フォルダーに書き込むにはどうすればよいですか? フォルダーには、整合性の低いプロセスからの書き込みアクセスを許可する明示的な必須ラベルを割り当てる必要があります。

アプリケーションの設計によっては、整合性の低いアプリケーションで使用されるフォルダーにファイルを追加する他の連携プロセスが存在する可能性があります。 他のプロセスも低整合性で実行されている場合、それらのプロセスによって作成されたファイルには、低い必須ラベルが自動的に割り当てられます。 ただし、他のパートナー プロセスの整合性が高い場合は、パートナー プロセス (ファイル同期サービスまたはユーザー エージェント) によって、低いフォルダーに自動的にラベル付けされていないファイルが作成される可能性があります。 パートナー プロセスは、低アプリケーションで使用されるフォルダーに中のファイルを作成します。低アプリケーションは変更または削除できません。

整合性メカニズムを使用すると、低い必須ラベルを持つフォルダーに子オブジェクト、ファイル、サブフォルダーを含め、各ファイル システム オブジェクトには一意のセキュリティ記述子があるため、それぞれ異なる高い必須ラベルを持つことができます。 低い必須ラベルが割り当てられているフォルダーの場合、低いプロセスで変更できるように、フォルダー内のすべてのファイルに低い必須ラベルを割り当てる必要があるという意図が多く存在します。 整合性メカニズムでは、必須ラベル ACE を親コンテナーからサブコンテナーと子オブジェクトに継承できるようにすることで、これをサポートしています。

必須ラベル ACE 型のデータ構造には、AceFlags フィールドを含む ACE ヘッダーが含まれています。 AceFlags フィールドは、任意のアクセスに使用される Access Allowed ACE 型など、他の ACE 型の継承フラグと同じ ACE 型の継承フラグを定義するために使用されます。 必須ラベル ACE は、 コンテナー継承 (CI) またはオブジェクト継承 (OI) に対して 継承可能として定義できます。 必須ラベル ACE を inherit_only (IO) にすることはできません。 コンテナーに継承可能な必須ラベル ACE が割り当てられている場合、必須ラベルはコンテナー自体と、継承が適用される子オブジェクトに適用されます。

継承可能な必須ラベルの例として、すべてのユーザー プロファイルの下に作成されたフォルダーの 1 つに低い必須ラベル (%USERPROFILE%\AppData\LocalLow) があります。 このフォルダーには、プロファイルが初期化され、低整合性アプリケーションによって既定で書き込み可能な最上位フォルダーとして意図されている場合、低い必須ラベルが割り当てられます。 次の図は、Icacls コマンドを使用して表示される AppData\LocalLow フォルダーの継承可能な必須ラベルを示しています。 Icacls が必須ラベルをサポートする方法の詳細については、「 付録 B: Icacls とファイルの整合性レベル」を参照してください。

必須ラベルの継承フラグは、ACE が (OI) および (CI) ACE であり、NO_WRITE_UP (NW) 必須ポリシーを持っていることを示します。 AppData\LocalLow フォルダーの下に作成されたすべてのサブフォルダーは、継承可能なラベルを継承します。

図 4 継承可能な低い必須ラベル

中間プロセスから新しいファイルまたはサブフォルダーを作成すると、新しいオブジェクトは低い必須ラベルを継承します。 次の例では、コマンド プロンプトは中程度の整合性レベルのプロセスで実行されています。 ファイル、newfile.txt、新しいフォルダー Temp が LocalLow フォルダーに作成され、両方のオブジェクトが親コンテナーから低い必須ラベルを継承します。 Icacls は、必須ラベルが (I) の指定で継承されることを示します。

図 5 子オブジェクトの必須ラベルの継承

必須ラベルの継承により、ファイル システム名前空間の一部で作成されるオブジェクトの整合性レベルの一貫性が確保されます。

継承と明示的なラベル

継承可能な必須ラベルを持つコンテナーで作成されたオブジェクトは、コンテナーから必須ラベルを継承します。 ただし、ファイルなどの新しいオブジェクトを作成するプロセスでは、CreateFile などの create 関数に対して、セキュリティ属性パラメーターに明示的な必須ラベルを指定できます。

作成プロセスがオブジェクト作成関数のパラメーターとして明示的なラベルを提供する場合、新しいオブジェクトには呼び出し元によって提供される明示的な必須ラベルが割り当てられ、親コンテナーから継承されません。 明示的な必須ラベルは、オブジェクトを作成するサブジェクト プロセスよりも高い整合性レベルを持つことができます。 サブジェクトによって提供される明示的な必須ラベルの整合性レベルは、親コンテナーの継承可能な必須ラベルの整合性レベルよりも高い場合があります。

継承のみの制限

継承専用 (IO) は、ACE がアタッチ先のオブジェクトへのアクセスを制御しないことを示すアクセス制御エントリのフラグです。 継承専用 ACE は、通常、コンテナー オブジェクトに割り当てられます。 継承専用 ACE は、コンテナー自体では有効ではありません。むしろ、コンテナーの子オブジェクトに適用されます。 新しいオブジェクトにINHERIT_ONLYラベルを設定する場合、整合性レベルが既定値より小さいサブジェクトには制限があります。 新しいコンテナー オブジェクトに渡される明示的なラベルが、既定よりもレベルが小さいINHERIT_ONLY ラベルである場合、ラベルは無効と見なされ、無視されます。 この制限の根拠は、低いサブジェクトがコンテナーを作成し、コンテナーにINHERIT_ONLYラベルを低く設定しようとすることです。 INHERIT_ONLY ラベルが受け入れられた場合、コンテナーの有効な整合性レベルは、暗黙的な既定の medium レベルになります。

さらに、サブジェクトは、サブジェクトの整合性レベルよりも高い整合性レベルを持つINHERIT_ONLY ラベルを定義することはできません。 たとえば、中程度のサブジェクトでは、整合性レベルが高いINHERIT_ONLY ラベルを定義することはできません。

保護された SACL とラベルの継承

SDDL では、明示的な必須ラベルを含む可能性がある、保護された SACL の定義がサポートされています。 保護された SACL は、セキュリティ記述子の SECURITY_DESCRIPTOR_CONTROL フィールドにSE_SACL_PROTECTED フラグを設定します。 アクセス権に関するLABEL_SECURITY_INFORMATIONとSACL_SECURITY_INFORMATIONの論理的な分離は、保護された SACL の動作に関しては完全ではありません。 必須ラベルは SACL に格納されます。 保護された SACL は、必須ラベルも保護されていることを意味します。

SECURITY_DESCRIPTOR_CONTROLでSE_SACL_PROTECTED フラグが設定されている場合は、必須ラベルも保護されます。

  • 保護された SACL に必須ラベル ACE がない場合、コンテナーから継承可能な必須ラベル ACE は適用されません (新しいオブジェクトには暗黙的な既定の必須ラベルがあります)。
  • 保護された SACL に必須ラベル ACE がある場合、コンテナーの継承可能なラベル ACE に対する変更は、このオブジェクトには影響しません。

SDDL の詳細については、「 付録 A: 必須ラベルの SDDL 」または 「Windows 整合性メカニズム リソース」を参照してください。

必須ポリシーでのアクセス チェックのしくみ

AccessCheck 関数は、必須ポリシーを適用します。 AccessCheck は、指定されたセキュリティ記述子と指定したアクセス トークンを比較し、 AccessStatus パラメーターでアクセスが許可されているか拒否されているかを示します。 AccessCheck 関数は、まず ClientToken の整合性レベルを pSecurityDescriptor の SACL の必須ラベルと比較して、必須ポリシーに基づいて、使用できないアクセス権を決定します。 必須ポリシーがチェックされた後、AccessCheck は目的のアクセス権と DACL で付与されたアクセス権を比較します。

既定の必須ポリシーでは、整合性の低いプロセスが整合性の高いオブジェクトへの汎用書き込みアクセスを取得できないようにします。 たとえば、既定では、整合性レベルが高いオブジェクトに対する汎用書き込みアクセスは、既定では整合性の低いプロセスによって拒否されます。 pSecurityDescriptor に必須の ACE が含まれていない場合、オブジェクトに中程度の整合性レベルを割り当てる暗黙的な必須 ACE が想定されます。 GenericMapping パラメーターは、汎用書き込みアクセスに関連付けられているアクセス権を決定します。 GenericMapping パラメーターがすべて 0 の場合、整合性チェックは、整合性の低い ClientToken に対する特定のアクセス権を付与しません。 整合性チェックが、必須ポリシーに基づいて呼び出し元が使用できる汎用アクセス権を決定した後、セキュリティ記述子の DACL を ClientToken と比較して、付与された残りのアクセス権を決定します。

ユーザー インターフェイス特権の分離 (UIPI) と整合性

ユーザー インターフェイス特権分離 (UIPI) は、低い特権のアプリケーションがウィンドウ メッセージを送信したり、高い特権のプロセスにフックをインストールしたりできないようにする制限を Windows サブシステムに実装します。 特権の高いアプリケーションは、低い特権のプロセスにウィンドウ メッセージを送信できます。 この制限は、 SendMessage および関連するウィンドウ メッセージ関数に実装されます。 低い特権のプロセスから高い特権のプロセスに送信されるすべてのウィンドウ メッセージがブロックされるわけではありません。 一般に、"読み取り" 型のメッセージ ( WM_GETTEXTなど) は、低い特権から高い特権のウィンドウに送信できます。 ただし、WM_SETTEXTなどの書き込み型メッセージはブロックされます。

UI 特権レベルはプロセス レベルであり、プロセスによって作成されたすべてのウィンドウに適用されます。 USER サブシステムは、プロセスが Windows グラフィックス デバイス インターフェイス (GDI) の最初の呼び出しを行うときに初期化します。 プロセスの初期化中に、USER サブシステムは をセキュリティ サブシステムに呼び出して、プロセスのプライマリ セキュリティ アクセス トークンに割り当てられた整合性レベルを決定します。 USER サブシステムは、プロセスの初期化中に UI 特権レベルを設定した後、変更されません。 スレッドの TokenIntegrityLevel を小さい値に設定しても、プロセスの UI 特権レベルや、そのプロセスまたはスレッドによって開かれたウィンドウには影響しません。

UIPI は、同じ特権 (または整合性) レベルのアプリケーション間のウィンドウ メッセージングの動作に干渉したり変更したりすることはありません。 UIPI は、次の動作をブロックすることで、低い特権のプロセスが高い特権のプロセスにアクセスできないようにします。 低い特権のプロセスでは、次のことはできません。

  • より高い権限で実行されているプロセスのウィンドウ ハンドル検証を実行します。
  • より高い権限で実行されているアプリケーション ウィンドウには、SendMessage または PostMessage を使用します。 これらの API は成功を返しますが、ウィンドウ メッセージをサイレント に削除します。
  • スレッド フックを使用して、より高い権限で実行されているプロセスにアタッチします。
  • ジャーナル フックを使用して、より高い権限で実行されているプロセスを監視します。
  • より高い権限で実行されているプロセスに対してダイナミック リンク ライブラリ (DLL) インジェクションを実行します。

UIPI を有効にすると、次の共有 USER リソースは、異なる特権レベルのプロセス間で引き続き共有されます。

  • 実際に画面画面を所有するデスクトップ ウィンドウ
  • デスクトップ ヒープの読み取り専用共有メモリ
  • グローバルアトムテーブル
  • クリップボードのトピック

画面への描画は、UIPI によってブロックされないもう 1 つのアクションです。 USER/グラフィックス デバイス インターフェイス (GDI) モデルでは、描画サーフェスを制御できません。 そのため、より少ない権限で実行されているアプリケーションは、より高い権限で実行されているアプリケーションのアプリケーション ウィンドウの表面に描画できます。

UI オートメーション アプリケーションの UIAccess

Microsoft UI オートメーションは、Microsoft Active Accessibility (MSAA) と呼ばれる以前のモデルよりも改善されたアクセシビリティ要件をサポートする Windows Vista モデルです。 アクセス可能なユーザー エクスペリエンスをサポートするように設計されたアプリケーションは、ユーザーに代わって他の Windows アプリケーションの動作を制御します。 すべてのアプリケーション (オートメーション クライアントとサーバー) が標準ユーザーとして実行されている場合(つまり、中程度の整合性レベル)、UIPI の制限が UI オートメーション モデルに干渉することはありません。

ただし、管理ユーザーが、UAC に基づく昇格された特権を持つアプリケーションを管理承認モードで実行する場合があります。 UI オートメーション プログラムは、UIPI が実装する制限をバイパスすることなく、デスクトップ上の昇格されたアプリケーションのグラフィックス UI を駆動できません。 特権レベル間で SendMessage に対する UIPI 制限をバイパスする機能は、 UIAccess と呼ばれるプログラムのアプリケーション マニフェストで特別なセキュリティ属性を使用して UI オートメーション プログラムで使用できます。

UIAccess プログラムのアプリケーション マニフェスト エントリの例を次に示します。

<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"> 
  <security> 
    <requestedPrivileges> 
    <requestedExecutionLevel 
      level="asInvoker" 
      UIAccess="true" /> 
    </requestedPrivileges> 
  </security> 
</trustInfo>

requestedPrivileges 属性に UIAccess="true" を 指定することで、アプリケーションは特権レベル間でウィンドウ メッセージを送信する際に UIPI の制限をバイパスする必要を示しています。 Windows Vista では、UIAccess 特権でアプリケーションを開始する前に、次のポリシー チェックが実装されます。

  • アプリケーションには、ローカル コンピューターの信頼されたルート証明機関証明書ストア内の信頼されたルートにチェーンされているデジタル証明書を使用して検証できるデジタル署名が必要です。
  • アプリケーションは、Program Files ディレクトリなどの管理者のみが書き込み可能なローカル フォルダー アプリケーション ディレクトリにインストールする必要があります。 UI 自動化アプリケーションに使用できるディレクトリは次のとおりです。
    • %ProgramFiles% とそのサブディレクトリ。
    • %WinDir% とそのサブディレクトリ。ただし、標準のユーザーが書き込みアクセス権を持つため、一部のサブディレクトリは除外されます。

除外されたサブディレクトリである %WinDir% サブディレクトリには、次のものがあります。

  • \デバッグ
  • \PCHealth
  • \登録
  • \System32\ccm
  • \System32\com
  • \System32\FxsTmp
  • \System32\Spool
  • \System32\Tasks

Windows Vista には、ローカル コンピューター ポリシーと、セキュリティで保護された場所から UIAccess プログラムを起動する必要がある要件を調整するためのグループ ポリシーのセキュリティ設定が用意されています。 この設定は、[ローカル セキュリティ ポリシー] の [ローカル ポリシー] の [セキュリティ オプション] で定義されます。 セキュリティ ポリシーは次のとおりです。

ユーザー アカウント制御: 安全な場所にインストールされている UIAccess アプリケーションの昇格のみ

既定では、この設定は有効になっています。 ただし、フォルダーから起動する必要がある UIAccess アプリケーション (アクセシビリティ 技術) が管理者専用の書き込みアクセスによって保護されていない状況がある場合、管理者は無効にすることができます。

UIAccess を要求する UI オートメーション アプリケーションが UIAccess 設定の要件を満たしている場合、Windows Vista は、ほとんどの UIPI 制限をバイパスする機能を使用してアプリケーションを起動します。 UI オートメーション アプリケーションがセキュリティ制限を満たしていない場合、アプリケーションは UIAccess 権限なしで起動され、同じまたは下位の特権レベルのアプリケーションとのみ対話できます。

UIAccess 権限で起動されるプロセス:

  • フォアグラウンド ウィンドウを設定する機能があります。
  • SendInput 関数を使用して、任意のアプリケーション ウィンドウを駆動できます。
  • 低レベルフック、生入力、GetKeyState、GetAsyncKeyState、および GetKeyboardInput を使用して、すべての整合性レベルの読み取り入力を持ちます。
  • ジャーナル フックを設定できます。
  • AttachThreadInput を使用して、より高い整合性入力キューにスレッドをアタッチします

標準ユーザーの UIAccess 権限を使用して起動されたアプリケーションには、アクセス トークンに少し高い整合性レベルの値が割り当てられます。 標準ユーザーの UIAccess アプリケーションのアクセス トークンの整合性レベルは、中程度の整合性レベルの値と、0x10の増分です。 UIAccess アプリケーションの整合性レベルが高いほど、中程度の整合性レベルの同じデスクトップ上の他のプロセスが UIAccess プロセス オブジェクトを開くのを防ぐことができます。