This is about secure configuration of Windows Services. I've noticed many many times that software developers, when designing software for the Windows platform, don't spend enough time on the principle of least privilege. Because it is so easy and quick, they install their services to run as LOCAL SYSTEM even though lower privileges would do fine, say, access to the file system and registry for binaries and configuration and network access to accept incoming connections and connect to a database. On Windows, there are, however, the users LOCAL SERVICE and NETWORK SERVICE.
Here is my question: Could I run a simple server (like described above, access to file system/registry, network access) as NETWORK SERVICE? Are these 2 users provided by MS for such a situation? Or am I as a developer supposed to investigate myself every single time which privileges are needed even if my service doesn't do anything extraordinary? If e.g. NETWORK SERVICE is not sufficient, which tools would I have to use in order to create a user in order to still follow the principle of least privilege?
I find this extremely relevant. If you succeed to inject code into a php application running on apache as www-data you still need a tedious privilege escalation to fully compromise the machine. On linux this particular issue is solved a lot better by default.
2 Answers
Here is my question: Could I run a simple server (like described above, access to file system/registry, network access) as NETWORK SERVICE? Are these 2 users provided by MS for such a situation?
Yes you can and you should. The network service account is (as I remember it) the least privileged machine account with limited permissions.You actually will get an Insufficient Exception, if it turns out, your application requests resources for which the Network Service account does not have the rights to. You would then simply grant rights to what ever resource you're trying to access and then build on that, but for your high level requirements you describe here, access to file/registry and network it should be sufficient.
True, if your application creates a new eventlog source or registry key, you would need to explicit grant the rights to the network service account, should be no big deal for you/devops.
You could also consider using a domain account, say if you want to isolate your application/service from how shall I say it: an over time fragmented permissions changes to the general Network service account.
I would suggest you read up on those accounts in general: https://msdn.microsoft.com/en-us/library/windows/desktop/ms686005(v=vs.85).aspx
If you succeed to inject code into a php application running on apache as www-data you still need a tedious privilege escalation to fully compromise the machine
regardless of priv. esc. of (www) is tedious or less tedious (personally I think it's pure fun), if you're at that point where you found a bug in your service that can be priv. escalated, it usually boils down to poor patch management on your box and not so much your service at that stage.
Privilege is the last think you may want to manipulate as a programmer and the reason is obvious: You seldom get appropriate error if app has insufficient privileges you won't get: Insufficient privilege exception.
That's a good reason why programmers avoid such a pain.
So at the best you should revise this part at the late phases of development when everything is working and have been tested. Then lower privileges and test full functionality up to where you are not OK.
The scheme you are looking after, is provided by the hosting layer of your app. For example an .NET apps by default have less privileges compared to Local System.
Finally if the hacker gets in by finding security problems in custom code of yours, then he is really interested and is not of the copy/paste exploits, guy so the hard part is breaking your code and finding a privilege escalation bug is just a matter of time/money. This Linux kernel privilege escalation vulnerability was available from 2012 (including most android devices) till recent.
