Service ACLs
A couple of months ago I have described WerSvc service starting on ETW and WNF. I have quickly mentioned Service ACLs and I believe it’s high time to dig in.
Services are not regular Windows Objects, and their ACLs are somewhat different, especially when you look inside, but they still exist. At the highest level we have a simple “who can do what” description, specifying Security Principals and actions they can (or cannot) perform. Actions are obviously adjusted to the nature of Windows Services. On the lower end, we can observe Security Descriptors in their beautiful binary form in a “Security” subkey for some services (such as gpsvc) listed in HKLM\System\CurrentControlSet\Services.
There is no native GUI for managing Service ACLs, but we still have couple of possibilities such as:
1. Group Policy Management offers ACL management in Computer Configuration, Windows Settings, Security Settings, System Services.
2. Process Explorer provides a nice GUI if you double click on Service-related process (pick any svchost.exe for testing), go to “Services” tab and click on “Permissions”.
And (of course!) we have a commandline superpowers as well. The tool allowing you to manipulate ACLs is sc.exe (don’t forget to use .exe extension when launching this command from PowerShell) offering you sdshow and sdset capabilities. The commandline uses SDDL. Funny and documented strings being a literal translation of the binary Security Description to a sequence consisting mostly of letters and semicolons. Assuming you had a chance to observe SD for gpsvc mentioned earlier, you will surely appreciate the charm of the SDDL obtained from “sc.exe sdshow gpsvc”.
Dealing with SDDL we have four areas to focus on:
1. Deny or Allow – it depends on the first letter of each Access Control Entry (ACE). D for Deny, A for Allow. Quite simple.
2. Permissions included in each ACE. It is always very dependent on the type of object and there is not easy to guess them for services judging by similarity to other objects. And it’s exactly why Microsoft engineers decided to fit a quick help into the sc.exe command. You can display it (and decipher all two-letter-pairs) by issuing “sc.exe sdshow gpsvc showrights”
3. Security principal – usually represented by the last two letters alias in each ACE. Such aliases are somehow documented, but not fully. Some time ago I spotted a weird behavior of ConvertStringSidToSid() effectively giving us a possibility to resolve each alias to SID and then to the human-readable name. If documentation is not enough, feel free to grab my piece of code doing “translation” of SDDL alias to name: https://github.com/gtworek/PSBits/blob/master/Misc2/SddlAlias2Sid.c
4. DACL vs SACL. Or the part starting with D: and with S: before ACEs. Only DACL (Discretionary Access Control List) manages the access rights. SACL (System Access Control List) is responsible for monitoring a.k.a. auditing and it’s why it’s not even visible for non-admin users, not having SeSecurityPrivilege in their tokens.
On top of that, I would add one thing more: “SCManager” can be used as a name (try “ sc.exe sdshow SCManager showrights “), but in such case ACL manipulation does not affect any service, but the Service Manager itself, leading to even more interesting scenarios.
When you know how it works, you can start playing with service ACLs, setting them through “sdset” parameters. The real fun begins when you deny (or just remove) specific rights, such as LC - SERVICE_QUERY_STATUS. Service works properly but cannot be easily listed. Have fun playing with ACLs, but please experiment in your VMs first. Just in case.