Folder with WRITE permission for a Windows Service and only READ permission for other apps

Question

I want to write some files from a Windows Service, and be able to read them from other apps. But I don't want other apps to be able to write to this folder.

Is there a standard folder for that (like there is App Data for storing data which does not have to be read from other apps)?

Bromberg

I would think this is more to do with permissions on the folder and what account you run the windows service under. – Paddy

@Paddy Yes. But I don't want to have to create a special folder and set its permissions if there is a standard folder for this. And I assume there is because it seems likely that services would like to make information available to apps, while preventing the apps from changing that information. – Bromberg

Does this service runs under local SYSTEM account ? This account usually has permissions to write to nearly all (local) directories. If the service runs under an user account (either local or AD user) it depends on the permissions of this user (in which groups it is, which group is in the ACL...). Anyway, It surely also depends on the "other apps", in which security context they run, don't rely on the fact that other apps run under a user account with less permissions and thus cannot write itself. – Chippewa

@RainerSchaack Goog point. The service runs under SYSTEM and therefore could write to most places. But I need a place that non admin users can read and not write. – Bromberg

You could use the C:\Program Files\CompanyName\ServiceInstallDir. The Windows system dirs are normally only readable by "normal" users. But be aware that this is not realiable. I would only do it this way if I had control over the system and the other apps (e.g. in a corporate infrastructure with Active Directory and all machines in a domain). – Chippewa

@RainerSchaack Well, I'm not getting any better ideas here, so you might as well post that as an answer. I'll be happy to upvote it. (If you can supplement it with a source for ProgramFiles permissions so much the better.) – Bromberg

Answer 1

It is important to consider that Windows sets permissions to read and write files based on the user (or group he is member of) and the ACL entries in the file system. So "preventing other apps to write to this folder" is really "other apps which are started under a normal user".

You could place the service in a directory under

C:\Program Files,

e.g.

C:\Program Files\CompanyName\ServiceInstallDir

If the service runs under the local SYSTEM account, it has the permission to write to this folder. And normal users have only read access.

But be aware that this is not bullet-proof and you never know if someone with admin rights changes the permissions on your folder after the install.

I would only do it this way if I had control over the system and the other apps (e.g. in a corporate infrastructure with Active Directory and all machines in a domain).

Be also aware that "other apps" could also be Windows services running under SYSTEM or another user with local admin rights, so they would also be able to write to your folder.

Another solution would be to run the service under a dedicated user account (either local or Active Directory), and set the permission of your folder so that only this user has modify rights.

Please note that you have to give this user account the privilege "Log on as service" (via Local Security Policy or AD GPO).

But even in this case: if some other (admin) user has Restore Privileges, he could circumvent the ACL.

Another important note:

Running the service under SYSTEM means that this service is highly privileged, which may be a security risk.

---

Important note from eryksun (see comments) Thank you !

See also https://blogs.technet.microsoft.com/voy/2007/03/22/per-service-sid/

So you can prevent other services to write to your files.

Chippewa

Since Vista (so for about 12 years), the service controller adds "NT SERVICE\<service name>" SIDs to the token of a service process for every service that it hosts. The actual SID value starts with the "NT SERVICE" domain (i.e. S-1-5-80), and an algorithm is used to transform the service name into the remaining unique part of the SID. You can show the computed SID for any service name via sc.exe showsid <service name>. – Oriental

Generally, an appropriate place for a service to store data is in a subdirectory of %ProgramData%, preferably as "<organization name>\<service name>" (e.g. "Contoso\SprocketManager"). The default inherited permissions there grant standard users the right to create subdirectories and add files, but you can set a custom security descriptor at the time of creating the directory. Give the service SID full control and only grant other users read and execute access. – Oriental

Thank you very much for your comment, eryksun. I think I have to refresh my knowledge a bit about the "new stuff" :-) I will add this to my answer – Chippewa

The linked blog mentions a critical point that I forgot. You have to configure SERVICE_CONFIG_SERVICE_SID_INFO for the service, since the default configuration doesn't add the service SID. – Oriental