プライマリトークンと偽装トークンの相違点

Question

一部のWindows APIはプライマリトークンを返し、一部は偽装トークンを返します。一部のAPIはプライマリトークンを必要とし、他のAPIは偽装トークンを必要とします。例えば

、LogonUserは通常、ログオンタイプ（dwLogonType）としてLOGON32_LOGON_NETWORKを使用している場合を除き、プライマリトークンを返します。ほとんどの場合、

、返されたハンドルは、あなたがへの呼び出しで使用できるプライマリトークンですCreateProcessAsUser関数です。ただし、LOGON32_LOGON_NETWORKフラグを指定すると、LogonUserはDuplicateTokenExを呼び出してプライマリトークンに変換しない限り、CreateProcessAsUserで使用できない偽装トークンを返します。

SetThreadTokenは偽装トークンが必要ですが、かなり同じように見えるImpersonateLoggedOnUserのいずれかがかかります。

CreateProcessAsUserとCreateProcessWithTokenWの両方がプライマリトークンを必要とし、両方のは、プライマリトークンがDuplicateTokenExを呼び出して偽装トークンから取得することができますが、トークンの種類はを何を意味するのですか？

用語集では、次の言葉：

access token

アクセストークンは、ログオンセッションのセキュリティ情報が含まれています。ユーザーがログオンするとアクセストークンが作成され、ユーザーの代わりに実行されるすべてのプロセスにトークンのコピーが作成されます。トークンは、ユーザー、ユーザーのグループ、およびユーザーの特権を識別します。システムは、トークンを使用して、セキュリティ保護可能なオブジェクトへのアクセスを制御し、ローカルコンピュータ上でさまざまなシステム関連の操作を実行するユーザーの機能を制御します。アクセストークンには、プライマリと偽装の2種類があります。

primary token

一般的にのみ、Windowsカーネルによって作成されたアクセストークン。そのプロセスのデフォルトのセキュリティ情報を表すプロセスに割り当てることができます。

impersonation token

サーバーは、セキュリティ操作でクライアントプロセスを「偽装」することができ、クライアントプロセスのセキュリティ情報をキャプチャするために作成されたアクセストークン。

しかし、それは完全には有用ではありません。誰かが "カーネル"のような大きな男の子の言葉を使いたいと思っていたようですが、これは他に（プロセスに割り当てられている以外に）プライマリトークンを使うことができ、カーネルの他に誰がアクセスを作成できるかトークン？

（これは、カーネルがカーネルモードで実行されるものの一部であり、エグゼクティブなどもあります）、つまりユーザーモードコードでもトークンを作成できるという意味ですか？ユーザーモードのコードでトークンを作成できる場合は、Object Managerオブジェクトの場合と同様に、システムコールを使用してトークンを作成する必要があります。

とにかく、基本的な質問に答える：トークンタイプの違いは何ですか？何か 通常はが作成されています。

Answer 1

友人はこの質問に正確に答えるKeith BrownのProgramming Windows Securityに私を紹介しました。

プライマリトークンは、プロセストークンと呼ばれることがありますが、偽装トークンはスレッドトークンと呼びます。プライマリトークンはプロセスにのみアタッチでき、偽装トークンはスレッドにのみアタッチできます。それで全部です。実際にはDuplicateTokenExを使用して自由に変換することができます（変換したいハンドルに必要なアクセス権があることが前提です）。本のページ115から

：

BOOL DuplicateTokenEx( HANDLE ExistingToken, // in DWORD DesiredAccess, // in LPSECURITY_ATTRIBUTES Attributes, // in, optional SECURITY_IMPERSONATION_LEVEL ImpLevel, // in TOKEN_TYPE Type, // in PHANDLE NewToken); // out

...

Typeパラメータは歴史的人工物です。 TOKEN_TYPE列挙型の定義を見ると、トークンは2つのカテゴリ、つまり偽装対1次トークンに分類されています。この命名法に執着しないでください。その意味は実際にはそれよりもはるかに簡単です。偽装トークンはスレッドにのみ添付でき、主トークンはプロセスにのみ添付できます。それだけで意味があります。したがって、OpenProcessTokenを介して以前に取得されたプロセストークンは、プライマリトークンでした。

非常に初期のバージョンのWindows NT（3.x）では、元々どこから取得したかに応じて、トークンでできることにはさらに厳しい制限がありました。そのため、トークンタイプが導入されましたトークンの使用目的。このテキストは、Windows NT 4.0以上を使用していると仮定しているため、偽装トークンを「スレッドトークン」と考え、プライマリトークンを「プロセストークン」と考え、DuplicateTokenExを使用して、必要に応じて2つの間で変換します。 Windows NT 4.0は、DuplicateTokenExを導入して2つの境界を徹底的に縮小しました。この機能のWindows NT 3.xバージョンDuplicateTokenは、偽装トークンのみを生成するようにハードコードされていました。実際にはSetThreadTokenへの最初の呼び出しが失敗するという愚かなバグを見ることができるはずです：コードがプライマリトークン（プロセスから取得したトークン）をスレッド（偽装トークンを必要とする）にアタッチしようとしています。 。それはノーではありません。

• どうやらImpersonateLoggedOnUser：厳密質問への答えではなく、問題に言及した

その他のもの：論理的な問題や愚かな歴史的問題の両方を解決するには、ここで修正されたコードですSetThreadTokenは気にしませんが、余分なマイルに移動し、プライマリトークンを偽装トークンに変換します。どうして？知るか？おそらく同様の理由から、一部のAPIは通話中の特権を有効にし、他のAPIは発信者が自分で特権を有効にする必要があります。

LogonUser（およびLsaLogonUser）は、通常ネットワークログオンを実行するユーザー（たとえば、83ページ以降）を想定しているため、おそらくネットワークログオンの偽装トークンを返します。

文書化されていないNTDLL関数ZwCreateTokenを使用してユーザーモードからトークンを作成することができます。これにはかなり珍しい特権が必要です（具体的には固有のSE_CREATE_TOKEN_NAME）。あなたはおそらく...