Restricting a Service s Network Ports

Reducing Service Privileges

As I've already said, a well-secured service would run under a service account that had exactly the privileges that it needed, and no more. But that would imply that Microsoft would have to create a separate service account for each service. While that's a nice idea, it might be a bit difficult to manage, so Microsoft observed something interesting:

Note 

It's not what privileges the service account has that matters. It's what privileges are in the token attached to the service's svchost.exe while it's running.

Now, in previous versions of Windows, that would be one of those "difference that doesn't make a difference" observations; whatever service account your service's svchost ran under would get all of its privileges, and that was that. But we've already seen in Chapter 2 that Vista has the ability to do some interesting filtering of tokens, so Microsoft employed that with services as well.

Developers Can Reduce Service Privileges

Here's how it works: when building a Vista service, a developer may optionally include some instructions to the SCM, telling it, "I only need the following privileges." Then, when the SCM loads the service, it creates the token for that service, as has been true in previous versions of Windows. But in Vista, the SCM doesn't just copy the service account's token to the instance of svchost.exe that's running the service; instead, that svchost.exe only gets the privileges that it needs.

In case that's not clear, imagine that you've got a service named CoolSvc that only needs, say, "bypass traverse checking," but runs in a svchost.exe started with the very powerful Local-System service account. When the service starts up, it says to the SCM, "hey, I only need bypass traverse checking," so SCM looks at the SID of the service account that started it-LocalSystem, which you will recall is equipped with about 4,731 privileges-and says "Holy frijoles, that's way more privileges than you need to get this job done," and issues the service its token with Local-System's token…but with all of the privileges ripped out except for bypass traverse checking.

Admins Can Also Reduce Service Privileges

But what if the developers of your services are lazy and don't bother specifying the limited privileges that CoolSvc can live with? In that case, you can tell the SCM what CoolSvc needs with sc.exe, the all-purpose service control application. The command to do that looks like

 SC <server> privs servicename privilege1/privilege2... 

In that command, you specify the list of the privileges with a single slash between them that the service needs, expressed in the shorthand "SEmumble" form. For example, if CoolSvc needed SeShutdownPrivilege and SeChangeNotifyPrivilege, we could inform Vista of that by typing

 sc privs CoolSvc seshutdownprivilege/sechangenotifyprivilege 

(That should be one long line; it may have broken on the printed page, but don't press Enter after "CoolSvc.") Once passed to the SCM, that information doesn't disappear; it's stored in a REG_MULTI_SZ entry called RequiredPrivileges in CoolSvc 's Registry key, and survives reboots. But how to find out if a service already contains these useful and security-conscious built-in privilege tips? You can then query the SCM to find out what privilege requests, if any, a service makes like so:

 sc qprivs servicename 

For example, I can ask the Interactive Services Detection Service what it thinks that it needs like this:

 C:\>sc qprivs ui0detect [SC] QueryServiceConfig2 SUCCESS SERVICE_NAME: ui0detect         PRIVILEGES       : SeTcbPrivilege                          : SeAssignPrimaryTokenPrivilege                          : SeIncreaseQuotaPrivilege                          : SeDebugPrivilege 

Aha, I guess I can see why Microsoft turned ui0detect off by default. Will ya look at the privileges that it needs: "act as a part of the operating system" and "debug other processes"-two of the Notorious Nine.

Tip 

As always with Windows, anything that changes a token doesn't take effect until the account-the service account, that is-logs off and then back on, so to see the effects of your changes, restart the svchost.

Again, let me stress that not every service has this privilege information built in. For example, try querying sc for the privileges on lanmanserver, the File Server service: there aren't any. That doesn't mean that the File Server service isn't allowed any privileges-it just means that Microsoft didn't employ their new technology to rein it in.

Note 

That's kind of a shame, I think. They're pretty vocal when talking about the security improvements in Vista, but a quick look at a few of the built-in Vista services shows that they've not been configured to reduce their privileges. But given enough time, we admins will probably figure out exactly what privileges we can restrict the Windows services to.

In the event that a service has no RequiredPrivileges Registry entry, then SCM treats that service just as services have been treated since NT 3.1: it gets a token with the full powers of its service account.

Special Case: Multiple Services Needing Different Privileges

So no RequiredPrivileges, no privilege limitation on its svchost.exe 's token; with a RequiredPrivileges entry in the Registry, our svchost.exe gets reduced privileges, right?

Almost-I left one detail out. Consider: what happens if a svchost.exe contains more than one service, and those services all have a RequiredPrivileges Registry entry?

For example, suppose we've got a svchost.exe running under LocalSystem. That svchost.exe contains Service1, which requires SeDebugPrivilege, and Service2, which requires SeShutdownPrivilege. Remember that even though there is more than one service in the svchost.exe, there is just one token, as it's svchost.exe that gets the token-there is no way to give Service1 and Service2 different tokens if they live in the same svchost.exe. So what's on that token? The union of the RequiredPrivileges values. In other words, SCM builds the svchost.exe a token containing both the SeDebugPrivilege and the SeShutdownPrivilege, and that means that Service1 has both privileges, as does Service2. Moral of the story: by default whenever you set up a new privilege, it gets its own svchost.exe. Unless you have a good reason otherwise, keep it that way, or you'll end up having done a lot of work to fine-tune the minimum privilege needs of a bunch of services, only to have them end up with a wide range of privileges anyway.

Reduced Privilege Summary

Vista changes service privileges in that services can enumerate exactly which privileges they need, or allows administrators to modify those lists of required privileges with the sc privs command. The effects of this are that

• In the case where a svchost.exe contains just one service, and that service has no information about its required privileges, then that svchost.exe and thereby that service get a token with the full privileges of the service account.

• In the case where a svchost.exe contains just one service, and that service has declared the privileges that it needs, then SCM will give that svchost.exe a token containing only the privileges enumerated by the service. (Although if the service requires a privilege that the svchost.exe 's service account lacks, then SCM can't give the token that privilege-the SCM cannot give an account privileges that it lacks.)

• In the case where a svchost.exe contains more than one service that has enumerated its required privileges, the SCM computes the union of all of those privilege needs and gives all of those privileges to the svchost.exe 's token.

• In the case where a svchost.exe contains a mixture of services that enumerate their required privileges and services that do not, SCM just copies the service account's token and gives that to the svchost.exe.

Warning 

And in case it's not obvious, configuring a service with a particular set of required permissions that does not include the complete actual set of required permissions will inevitably cause the service to fail. For example, NetworkService possesses only a few simple permissions, none of which is SeDebugPrivilege. So running a service in a svchost.exe under NetworkService and specifying that the service requires the SeDebugPrivilege will cause that service to fail, every time.