3

We have an application which is not per user and can be used by multiple users simultaneously. Data is also shared by all users.
The path to the data folders we use is ProgramData\OurAppName\Data (post Vista), and we give full control to all users, so that our application run by them can make changes to files under the Data folder.

Now the issue with this is, now any other application (malware/virus) can also modify files - i.e. an attack can be made on our application's data files. Our applications is a Win32 Desktop application.

Is there any way in which we can restrict access to the Data folder to only our applications?

S.L. Barth
  • 5,486
  • 8
  • 38
  • 47
Abhishek Jain
  • 131
  • 1
  • 2
  • Have you thought of encrypting your files? That would prevent any external reading/modification but would not prevent deletion or modification resulting in a broken file... Also look at DLP solutions that have daemons that monitor files and folders. Maybe that's a way to go? – David Brossard Feb 19 '15 at 16:29

3 Answers3

1

Applications on Windows Operating Systems run in the context of the user executing it and therefore inherit the ACL of that user.

When looked at abstractly your program is doing nothing more than Word (winword.exe) or Excel (excel.exe) is doing with .doc or .xls files. You shouldn't need to restrict access of the data to only the application, risk reduction comes though:

  • limiting the users who have access to the data (ACL's, aka file permissions, ideally though a group)
  • limiting the operations a user can do (e.g. application installation to prevent malware)
  • application whitelisting
  • anti-malware protection
  • auditing for data integrity
idarryl
  • 113
  • 10
0

On Unix, I would suggest that you run that application as a particular user or group and limit the permissions on that folder to the user and group.

You could do the same on Windows, but not as easily. If you know all of the users who will run the application, can you add them to a particular group, then give the group full control over that file?

TimC
  • 552
  • 5
  • 12
  • Is it a good idea on windows? 1. Our Installer create an user account / group (say, XXX with no special permissions) on the machine 2. Change the access permissions on the directory where the data files are stored, C:\ProgramData\ABC\Data by default. This directory should really only be accessible to Administrators and the XXX user account created. 3. Whenever user runs any of our applications, we impersonate to run the our application’s process as XXX user. We can do various checks like we do so only when we are not running as administrator already. – Abhishek Jain Feb 04 '15 at 10:49
0

Android essentials does when installing applications. Each app gets a group assigned to it, and only that group can access the data for the app. In a Unix based system this is rather simple to implement. Windows gets a bit harder.

Access Control Lists

What you can do is create a custom Discretionary Access Control List (DACL) for your application. These can be converted into Security Descriptors which can be used with functions like CreateDirectory. The DACL will contain all the information about who can access the folder. In this case you'll probably want to create a Windows group for the application.

When you create your directory you can restrict access to the DACL you create. When your application runs/needs to access the directory it acquires the DACL, and uses it in subsequent system calls. These aren't the easiest Windows object in the world to work with, but they do what you want.

More than you probably want to know about Windows security descriptors and access control.

More on Creating DACLs

Creating Users

You can create a User Profile in Vista+. More than a little tricky because Windows wasn't designed for this. Impersonating a logged on user requires some type of access token for the user you're attempting to use. There are multiple functions that would return such a token:

BOOL WINAPI ImpersonateLoggedOnUser(
  _In_  HANDLE hToken
);

hToken [in]

A handle to a primary or impersonation access token that represents a logged-on user. This can be a token handle returned by a call to LogonUser, CreateRestrictedToken,DuplicateToken, DuplicateTokenEx, OpenProcessToken, or OpenThreadToken functions. If hToken is a handle to a primary token, the token must have TOKEN_QUERY and TOKEN_DUPLICATE access. If hToken is a handle to an impersonation token, the token must have TOKEN_QUERY and TOKEN_IMPERSONATE access.

LogonUser requires a password. You probably don't want to hardcode one into your application. DuplicateToken only generates impersonation tokens, which can't be used with CreateProcessAsUser (which is our end goal). Now we're left with a bunch of functions that require an existing token to duplicate and start from. That means you're left with the current user's token which is not what you want.

Creating tokens is pretty much out of the question. That operation is often only done by LSASS, and I wouldn't be surprised if this whole behavior was flagged by Anti-viruses. In Windows this approach is probably a bad idea, and not worth the amount of flaming hoops you would have to jump through to make it work.

RoraΖ
  • 12,317
  • 4
  • 51
  • 83