保護IPCカーネルとユーザーモードアプリケーションの間
現在、Windows用のセキュリティソフトウェアを開発しています。このアプリケーションは、ユーザーモードで実行されるサービスとカーネルモードのドライバーで構成されます。これらの2つは通信する必要があるため、サービスはドライバーからデータを取得し、実行するアクションを送信できます。通信はIOCTLを使用して実装されます。
問題は、サードパーティのソフトウェアがこれを悪用できないように、この通信をどのように保護するかです。
ドキュメントから、デバイスファイルに権限を設定する方法を学びましたが、これらは非常に制限されています。権限を付与できるのは、admin-groupまたはSYSTEMアカウントのみです。
サービス自体は昇格された特権を必要としないため、あまりにも多くの権限（最小限の特権の原則...）でサービスを実行したくありません。
私たちのアプローチは、Linuxでよく行われているように、サービスを実行する権限が制限されたローカルユーザーを作成することです。
また、IOCTL呼び出しからユーザーを取得することもでき、それらを期待されるユーザーと比較することで、アクセスを「許可」および「拒否」することができます。
今問題は、このアプローチは安全ですか？それとも、私たちには見られない欠陥がありますか？私たちがこのアプローチに従う人を見つけることができなかったからです。
-編集-
私たちが考慮した考慮事項（ユーザーのパスワードが秘密であると想定）：通常のユーザーとして、アプリ定義のユーザーになりすますことができないため、ドライバーと通信できません。 Admin/SYSTEMにはこの可能性があります（少なくともパスワードは変更できます）。ただし、デバイスの権限が設定されている場合、Admin/SYSTEMはドライバと通信することもできます。
保護されたプロセスを起動できるELAM（早期起動アンチマルウェア）ドライバーがあります。これでおそらく問題は解決しますが、現時点ではMicrosoftから必要な証明書を取得できません。
サービスを特定のユーザーとして実行する必要がない場合は、独自のユーザーとして実行する必要があります。より正確には、 サービスアカウント 、場合によっては 仮想アカウント として実行する必要があります。ユーザーアカウントとは異なり、サービスアカウントはサービスとしてマシンにログインするためのアクセス許可を除くを必要としませんが、それ以外はおおまかに似ています。 ACL（ドライバーオブジェクトを含む）でそれらのアクセス制御エントリを定義でき、ファイルシステムやプライベートレジストリハイブなどに独自のプライベートロケーションを設定できます。
Windowsには3つの組み込みサービスアカウントがありますが、独自のアカウントを作成することもできます（ドメインコントローラーまたはローカルのいずれかを使用）。組み込みのものは、Windowsに付属するサービスとサードパーティのサービスの両方で広く使用されています-Local Service、Network Service、およびLocalSystem（大文字と小文字が区別されないことを確認してください。私はLOCALSYSTEMなどと書かれていることも確認しました）。最初の2つは、通常のユーザーアカウントと同様の（ただし、まったく同じではない）特権を持っています。最後の権限には、組み込みのAdministratorアカウントでさえデフォルトで取得できない権限を含め、プロセスが持つことができるすべての権限があります。もちろん、これらは共有アカウントです。これらのアカウントのいずれかで実行されているサービスが悪意のある、または侵害された場合、そのアカウントの他のサービスが参照または実行できるすべてのサービスを参照および実行できます。
仮想アカウントは、カスタムメイドのサービスアカウントよりも便利であることを目的としていますが、同様のレベルのセキュリティを提供します。パスワードを作成したり管理したりする必要はありません。手動で作成したり、サービスログイン用に設定したりする必要はありません。一般に、パスワードは「そのまま機能する」はずです。ただし、Win7/Server 2008 R2以降でのみ使用できます。 Vista/Server 2008以降、すべてのサービスは自動的に一意のセキュリティID（SID）を持っています 他のSIDとは異なります（ユーザー、コンピューター、整合性レベル、AppContainer機能など）。このサービスSIDは、サービスの名前（表示名ではなく実際のサービス名）に基づいています。実際には、存在しないサービスのサービスSIDを取得することができます。呼び出された）。 Win7以降では、サービスがこのSIDを「仮想アカウント」として使用することが可能です（サービスは、NTという名前のアカウントに「ログイン」しますNTサービス\ <サービス名>Local Serviceなどとは対照的に）。
あなたが説明するシナリオでは、ドライバーのデバイスオブジェクトに（SDDLを使用して、ドライバーの作成に使用しているフレームワークを介して）ACLを設定し、NT SERVICE\<servicename >（および、おそらくACLを上書きまたは無視できるlocalsystemアカウント）がデバイスにアクセスできます。これは、サービスがその仮想アカウントを使用して「ログイン」しているかどうかに関係なく機能します。それは、そのSIDに関係なく（プロセスのセキュリティトークンは、ほとんどの場合、複数のSIDを持つことができます）。呼び出しプロセスのユーザーを取得し、それを予想されるサービスアカウント（仮想またはその他）と比較する追加のチェックを追加しても、おそらく害はありませんが、必要はありません（ただし、「否定」を含むテストを必ず記述してください）アクセス拒否エラーで失敗するはずのテスト！）