The previous answer didn't appear to address the questions directly, so I thought I would add to it.
- 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:
- Running as LOCALSYSTEM - so if this service is compromised, the attacker
owns Everything, and immediately.
- 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.