web-dev-qa-db-ja.com

Windowsで、フォルダー、サブフォルダー、およびファイルへのアクセスを一部のアプリケーション(ユーザーではない)のみに制限する方法

ユーザーごとではなく、複数のユーザーが同時に使用できるアプリケーションがあります。データはすべてのユーザーによって共有されます。
私たちが使用するデータフォルダーへのパスはProgramData\OurAppName\Data(Vista後)であり、すべてのユーザーにフルコントロールを与えて、ユーザーが実行するアプリケーションがDataフォルダーの下のファイルを変更できるようにします。

これに関する問題は、他のアプリケーション(マルウェア/ウイルス)もファイルを変更できることです。つまり、アプリケーションのデータファイルに攻撃を加えることができます。私たちのアプリケーションは、Win32デスクトップアプリケーションです。

Dataフォルダーへのアクセスをアプリケーションのみに制限する方法はありますか?

3
Abhishek Jain

Windowsオペレーティングシステム上のアプリケーションは、それを実行するユーザーのコンテキストで実行されるため、そのユーザーの [〜#〜] acl [〜#〜] を継承します。

抽象的に見ると、プログラムはWord(winword.exe)またはExcel(Excel.exe)が.docファイルまたは.xlsファイルを使用して実行していることと同じです。データへのアクセスをアプリケーションのみに制限する必要はないはずですが、リスクの軽減は次のようになります。

  • データへのアクセス権を持つユーザーを制限する(ACL、別名ファイル許可、理想的にはグループを介して)
  • ユーザーが実行できる操作を制限する(マルウェアを防止するためのアプリケーションのインストールなど)
  • アプリケーションのホワイトリスト
  • マルウェア対策保護
  • データの整合性の監査
1
idarryl

Unixでは、そのアプリケーションを特定のユーザーまたはグループとして実行し、そのフォルダーのアクセス許可をユーザーとグループに制限することをお勧めします。

Windowsでも同じことができますが、それほど簡単ではありません。アプリケーションを実行するすべてのユーザーがわかっている場合、それらを特定のグループに追加して、そのファイルに対するグループのフルコントロールを与えることができますか?

0
TimC

Android Essentialsは、アプリケーションをインストールするときに行います。各アプリにはグループが割り当てられ、そのグループのみがアプリのデータにアクセスできます。 Unixベースのシステムでは、これは実装がかなり簡単です。 Windowsは少し難しくなります。


アクセス制御リスト

あなたができることは アプリケーションのカスタム任意アクセス制御リスト(DACL) を作成することです。これらはSecurity Descriptorsに変換でき、CreateDirectoryなどの関数で使用できます。 DACLには、フォルダにアクセスできるユーザーに関するすべての情報が含まれます。この場合、おそらくアプリケーションのWindowsグループを作成する必要があります。

ディレクトリを作成するときに、作成するDACLへのアクセスを制限できます。アプリケーションが実行される/ディレクトリにアクセスする必要がある場合、DACLを取得し、それを後続のシステムコールで使用します。これらは、世界で最も操作しやすいWindowsオブジェクトではありませんが、望みどおりの動作をします。

おそらくWindowsのセキュリティ記述子とアクセス制御について知りたい以上です。

DACLの作成の詳細


ユーザーの作成

Vista +ではUser Profileを作成できます。 Windowsはこのために設計されていないので、少し注意が必要です。ログオンしているユーザーを偽装するには、使用しようとしているユーザーのアクセストークンのタイプが必要です。そのようなトークンを返す 複数の関数 があります:

BOOL WINAPI ImpersonateLoggedOnUser(
  _In_  HANDLE hToken
);

hToken [in]

ログオンしているユーザーを表すプライマリまたは偽装アクセストークンへのハンドル。これは、LogonUserCreateRestrictedTokenの呼び出しによって返されるトークンハンドルにすることができます。 、DuplicateTokenDuplicateTokenEx OpenProcessToken、またはOpenThreadToken関数。 hTokenがプライマリトークンのハンドルである場合、トークンにはTOKEN_QUERYおよびTOKEN_DUPLICATEアクセスが必要です。 hTokenが偽装トークンのハンドルである場合、トークンにはTOKEN_QUERYおよびTOKEN_IMPERSONATEアクセス権が必要です。

LogonUserにはパスワードが必要です。おそらく、アプリケーションにハードコードしたくないでしょう。 DuplicateTokenは、CreateProcessAsUserで使用できない偽装トークンのみを生成します(これが私たちの最終目標です)。これで、複製して開始するために既存のトークンを必要とする一連の関数が残されました。これは、現在のユーザーのトークンが残っていることを意味しますが、これは必要なトークンではありません。

トークンの作成はほとんど問題外です。その操作は多くの場合LSASSによってのみ実行されます。この動作全体がアンチウイルスによってフラグが立てられても、私は驚かないでしょう。 Windowsでは、このアプローチはおそらく悪い考えであり、それを機能させるためにジャンプする必要がある炎のようなループの量に見合う価値はありません。

0
RoraΖ