Windows - Use Local Service and/or Network Service account for a windows service

Question

I've created a window's service that monitors files on a specific directory on our Windows OS. When a file is detected, the service does some file I/O, reads the files, creates sub-directories, etc. This service also uses database connectivity to connect to another server. My plan is to have the service run as the default "Local Service" account. Since I need to allow write/read privileges, which apparently the "Local Service" account does not do by default, I'm going to explicitly set "Full Control" privileges for the "Local Service" account on the folder that I'm reading/writing to and from.

I believe the above is a good . My question is, for the folder that I'm reading and writing to, do I need to setup a "Network Service" role with full control access? I'm wondering since my service uses database connectivity to another server, if I'll need the "Network Service" account setup.

I may be misunderstanding what the "Network Service" account does.

Answer 1

The NT AUTHORITY\NetworkService account is only needed when you're communicating with other computers in a domain that need your machine's credentials for access control. It is not required for simple Internet/network access. It is only necessary for specific purposes in an Active Directory domain.

Also the entire point of the NT AUTHORITY\LocalService account is that it has minimum privileges on the system. Giving it more privileged decreases the security of the many services on your system designed to run at the low privilege level it was designed to proffer. If your service requires privileges above and beyond those, you should create a new account for it with the necessary privileges and set that account in the Log On tab of the service's properties. (This can also be done programatically.)

You could also run it using the NT AUTORITY\LocalSystem account, which has unlimited access to your system, but I assume you wanted to use the LocalService account for the increased security it provides.

Answer 2

The other answers confirm what you say about using Local Service. To summarize, Local Service is the recommended account to use with your service, unless you need the extra Active Directory SSPI features of Network Service.

For restricting read/write access to a specific folder, you can do better than just giving access to the generic Local Service account though. The problem, as others have pointed out, is that this would also give read/write access to all other services running as Local Service and if all services did this then gradually Local Service would receive access to more and more important resources.

The solution is to instead ACL your folder using your specific service SID. Only your own service process has your service SID associated with it, so this locks down your resource even further. You can view the service SID using sc showsid <service name>. The service SID is generated from the service name, so it will be the same on all machines.

To enable service SID usage by your service, use ChangeServiceConfig2 with the SERVICE_SID_INFO structure to set SERVICE_SID_TYPE_UNRESTRICTED. You can also set SERVICE_SID_TYPE_RESTRICTED to get an even more restricted SID that only allows write access to resources explicitly allowed with your service SID.

This link has the high-level descriptions of service SIDs and restricted service SIDs: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/hh125927(v=ws.10)

Answer 3

The previous answer didn't appear to address the questions directly, so I thought I would add to it.

1. My plan is to have the service run as the default "Local Service" account. I'm going to explicitly set "Full Control" privileges for the "Local Service" account on the folder that I'm reading/writing to and from. I believe the above is a good plan.

Personally, I don't see a big issue with this plan. With BUILTINs, the choice is between:

1. Running as LOCALSYSTEM - so if this service is compromised, the attacker owns Everything, and immediately.
2. Running as LOCALSERVICE - so if this service, or any of the many other services running under this account, are compromised, the attacker has access to one extra directory.*

Arguably, adding a few extra ACLs to be able to use the second option is preferable. Yes, the safest option for a low-privilege but highly security-sensitive service would be to run under a custom tailored, low privilege service account. But unless you want to create a new account/manage passwords for every service you deploy, using LocalService for minor non-sensitive tasks is not such a terrible thing. You just need to make a responsible decision based on these considerations, like what is in that directory or that database, impact if they are breached etc.

Although again, per least privilege principle, you should only set Full Control if Modify is really not sufficient.

2.My question is, for the folder that I'm reading and writing to, do I need to setup a "Network Service" role with full control access? I'm wondering since my service uses database connectivity to another server, if I'll need the "Network Service" account setup.

If your database required Windows Integrated/SSPI login, then yes, you would need to use NetworkService (or a domain service account) everywhere, i.e., RunAs and directory permissions. Assuming you also granted your computername$ or domain account access to this database. I doubt you are doing that, so if it uses normal username/pwd authentication, you should be able to do everything with LocalService. You need to grant only one account rights on that directory, whichever you use in your RunAs, not both.

3.I may be misunderstanding what the "Network Service" account does.

LocalService/NetworkService are almost identical accounts on the local computer. The difference mainly is what they can do on the network. NS can access some network resources because it appears on the network as a real (computer) account. But LS will appear as ANONYMOUS, so it will be denied mostly everything on the network.

By the way, you should be using a Scheduled Task for this, not a service.

*From Vista onwards, due to service isolation, one compromised LocalService process cannot easily attack another. Each LocalService/NetworkService service process/instance gets its own unique logon session SID (unique owner), unlike Windows 2003. But I'm not sure this is perfect and fully mitigates the DACL vulnerability on files and resources. Restricted SIDs and write-restricted tokens are mentioned in this context.