2

Unixでは、あるユーザーに代わって何らかのアクションを実行する場合、システムプログラムは通常seteuid（UID）（setegid（）を伴う）を呼び出して最初にそのユーザーに切り替え、アクションを実行し、終了時にseteuid（を使用してスーパーユーザーに戻ります。 0）。seteuid（）の時間は、1〜数マイクロ秒のオーダーです（つまり、ファイルの操作やCGIプログラムの実行などのアクションに比べてかなり安価です）。

私はWindowsAPIに精通していません。Windowsでも同じことをしますか（ただし、ImpersonateLoggedOnUser（）+ RevertToSelf（）API関数を使用します）？一般的に、これらの機能はどれくらい速いですか？

4

1 に答える 1

2

ほとんど同じですが、覚えておくべき重要な違いが1つあります。言及したWindows APIには、有効なトークンへのハンドルが必要です。

つまり、SYSTEM（またはSeTcbPrivilegeを持つプロセス）として実行している場合でも、ログオンしているユーザーを偽装する必要があります。

ユーザーはさまざまな方法でログオンできます。

  • 物理的なコンピューターで対話する
  • リモートデスクトップセッションを介して
  • ファイル共有、名前付きパイプ、メールスロット、RPC、その他すべての上に構築されたMicrosoftネットワーク接続のほとんどすべて。

プロセスを作成すると、ほとんどの場合、現在のトークンを継承します。

IISでKerberos、NTLM、またはHTTPBASIC認証を使用したかどうかは関係ありません。すべてWindowsによって認証されているため、トークンを取得します。一方、TomcatのHTTP BASIC認証ではWindowsトークンが提供されないため、偽装は不可能です。

トリッキーな部分があります。

考えてみると、トークンは実際には、承認（DACL）と監査（SACL）用のアクセス制御リストを備えた単なるメモリ構造です。これは、認証パッケージ（AP）によって作成されます。トークンを作成するのはAPです。また、UnixのPAMのように、APはカスタムコードに置き換えることができます。

実際のところ、オープンソースのsetuid認証パッケージが存在します。CVSをWindowsNTに移植した人々は、SeTcbPrivilege（ルートに相当するもの）を持っている限り、薄い空気からトークンを作成するAPを作成する作業を行いました。私はそれを試したことがありませんが、それは不在のユーザーのためにローカルマシン上にトークンを与える可能性があります。コードはかなり古いです（昇格されたトークンのみを作成します）が、それ以外にLGTMです。認証、パスワード、またはスマートカードは含まれないため、その構成されたトークンで実行されているプロセスは、それを使用して別のコンピューターへの認証を行うことはできません。

結論として：

  • 一般的な考え方は同じです
  • ルールに従ってプレイする場合、ログイン手順や場所に関係なく、ログオンしたユーザーになりすますことしかできません。
  • あなたはその振る舞いを変えることができます、しかしそれは
  • 内部の動作はほぼ同じであるため、偽装はおそらくUnixとWindowsで同じくらい高速です。違いに気付かない可能性があります。

提案： Programming Windows Securityの私のコピーはすべてコーヒーから黄色で、ポストイットのメモがぶら下がっていてページが破れています。このテーマに関するこれまでで最高のテキストです。Windowsのセキュリティを理解したい場合は必読です。

于 2012-09-07T03:54:05.800 に答える