How to Restrict a Windows Service Account to Reading/Writing from a Specific Folder

[RodDaSilva]

Hi,

New here but not new to Windows. I have a software requirement that I am surprised I can't seem to find an answer for.

I have written a Windows Service. I have created an installer for this service. This installer (when run as Administrator) creates a new user, provides the user with necessary "SeServiceLogonRight" rights, and then installs the Windows Service to run as this new user. Specifically I do NOT want the Windows Service running as Local Service, Local System or Network Service as I don't want it to have that elevated rights those service accounts enjoy.

The installer goes on to give this new user read/write permissions to the install directory and removes all other inherited permissions on the folder, essentially ensuring that only this user (and the Administrator) can access the installation directory, but no other users.

When I start the service all is well in the world and the service can read/write to the installation directory and other users cannot access this directory.

However, because the new user is a member of the "Authenticated Users" group it still has access to the rest of the machine. For example I can write code in my service to read and write to the C:\. I want NOT to be able to do that.

I want to give confidence to the Admins that install my service that it can ONLY read/write to its designated installation directory- i.e.; that it is IMPOSSIBLE for the Window Service to access any other part of the File System. Essentially I want to sandbox the Windows Service running as this new user to be rooted in that directory. How can I achieve this?

IOWs, how can I ensure my service runs with "least privileges" so that it only has file system permissions rooted at that installation directory and no others. Note that Group Policy isn't an option. The solution must work on a standalone Windows machine (server or client). I am targeting Windows 8.1 & Windows Server 2012 and up.

I believe it would be possible to Deny access to any other directory on the machine to this new user. However, this involves manipulating the security that is already set on the Windows machine. What I am hoping to be able to do is set security only on the new user that the installer has created such that the requirement is met. Does anybody have any ideas how I can achieve that? Seems to me it should be possible but I haven't found a way to pull it off.

Thanks,
Rod

 

[Neemobeer]

"Authenticated Users" really only means it can access standard user domain access. As far the local system it's running on just make sure the account it uses is a member of "standard users" group this is the least privileges group that has access to everything it needs to use the system.

 

[RodDaSilva]

So I added the user to the standard "Users" group and restarted the Windows Service but it can still read/write the C:\ drive without an issue.

 

[Neemobeer]

Then your admins have granted to much access. By default regular users cant write to C:\ only read and execute.

 

[RodDaSilva]

That's not what I am starting to understand. It seems that reguarlar users are by design allowed to read/execute/create files & folders the root of all drives on a system. See here: Permissions for system drive root directory (usually C:\) must conform to minimum requirements..

Further experimentation, however, has shown that while my service can create/read and delete files in the root of the C: drive (and other drives - D: , E: etc.,) it has no access to key locations on the drive such as C:\Users\OtherUser\..., C:\Windows\System32\ and C:\Program FIles, etc.,.

So I assume I can't do what I am trying to do "by design" of Windows and that the Windows Security team does not deem it a security risk to allow standard users to access the root of drives for the purpose of creating/reading/deleting files & folders.

 

[Neemobeer]

They should have read, execute and (create folder / append data) to the root and modify to subfolders and files.

 

[RodDaSilva]

So you are confirming then that there is nothing my installer can do to "configure" the new user it is creating in order to remove those permissions (i.e.; to prevent read,execute and create folder / append data) to the root and modify to subfolders and files)?

 

[Neemobeer]

You could set deny permissions since they have precedence over allow, but I wouldn't you'll likely break the application.

 

[RodDaSilva]

If I Deny this user for C:\ would they then be denied for C:\Program Files\MyApp\ ? IOWs if you are denied for any portion of the path are you denied for the entire path? (Never worked iwth Deny permissions so am not sure).

Thanks,
Rod

 

[Neemobeer]

Potentially if the permissions are propagated manually or via inheritance.

No to the partial path.
If you have allow to C:\ and deny C:\users and allow C:\users\user they can get to user but can't drill down to the path. They would have to go directly to the full path.

 

[RodDaSilva]

So I gave it a try - adding to my installer code to Deny all access to the root of every Drive on the machine to the user running the Windows Service. First, the install took a lot longer as the Deny permissions appeared to be added to every file/directory on each drive. Second, as you predicted, it broke the service (it could no longer start). Third, even if it worked, I didn't like it because it changes "existing" security on the machine, something I do not want to do. So I will leave it the way it was - as Windows design intended - with the service having access to C:\ but not to other more sensitive directories.

Thanks for your feedback/help.
Rod

 

[Neemobeer]

Figure it would. Running a service as a standard user being only the member of 'Domain Users' is any CISO's wet dream Most of the time people are lazy and give those accounts domain admin rights. As a domain user only account is considered following least privileged security practices and should pass any security audit.

 

[RodDaSilva]

Its actually better than that. The account created during the install is a local (not a Domain) account. I have worked hard to ensure that the service has only the permissions it needs and nothing more.

 

[Neemobeer]

A local account should be fine as long as it doesn't need to authenticate to a network resource.

 

[RodDaSilva]

It doesn't.