Summary

Service Isolation

Beyond session separation and privilege reduction, Vista takes service lockdown a step further and lets you set up "service isolation." The whole idea of service isolation is to completely remove a service's ability to modify anything on the system except for some small number of objects. That way, if the service stops working for good and starts working for evil, then you have strongly circumscribed the potential damage that it can do. For example, if a given service fell prey to a buffer overflow bug and some miscreant wrote a worm that tried to exploit that bug, then the first thing that the jerk would try to do in the worm would be to install a rootkit on your system. But installing a rootkit involves copying files and fiddling with the Registry, and the whole idea behind service isolation would have already kept the service from being able to modify almost anything on the system. The service would almost certainly not be able to write to the parts of the Registry and file system that would be necessary to get that rootkit installed…and so the worm would fail.

How Service Isolation Works

Microsoft had to make a few structural changes to Vista to make service isolation possible. In brief, they are:

• Every service gets its own SID called, not surprisingly, a "service SID," which can be used to identify that service in a file, Registry, or other type of permission.

• Every service can optionally be restricted such that the service can write to a given object only if that object has an access control entry on it that grants write access specifically to that service's SID; the service account's SID is of no help to an isolated service when that service wants to write.

• That restriction can be either built into a service by the service's developer, or an administrator can specify that restriction with sc.exe, as we'll see later.

The key to understanding service isolation is, as I've already suggested, that services typically need to write to something-a file, folder, database, Registry key, Active Directory object, or the like-in order to be useful. But of course those are all securable objects, as you'll recall from Chapter 4, and so a service needs a write ACE on the securable object that matches an SID on the service's token, or it can't get its job done.

In the pre-Vista days, services got their SIDs from their service accounts and whatever small number of groups those service accounts belonged to. Those were the only SIDs that a service could use to identify itself to an object when hoping to find that the object had a "write allowed" ACE with a matching SID. In Vista, services get not only their service account's SIDs on their svchost.exe 's token but they may also optionally get their own SIDs. Using that very specific service SID, Vista's SCM lets you get very, very specific about what objects a given service can modify.

For example, when reengineering the EventSystem service, which manages the event logs, Microsoft looked at how the event logs worked and said "hey, the only files that EventSystem ever needs to write to are the event logs themselves, a bunch of files in \windows\system32\winevt with the extension .EVT.": Vista's service isolation allowed Microsoft to accomplish that. Let's see how….

Restricting a Service's SID

The first piece to understanding service isolation involves understanding restricted SIDs. Under Vista, a developer or administrator can tell the SCM to modify the way that it creates a svchost.exe 's token. If instructed, SCM will build the svchost.exe 's token so that it gets the service account's SID, as before, but with the addition of a notation that says, "this SID is not good for any ‘write' operations."

In other words, a service running in a svchost.exe with this SID can read anything that the service account can read, but when it comes to writing anything, then Vista won't let the service use its service account's SID. This is called giving a service a "restricted token."

You can restrict a service's SID with the following command:

 sc sidtype servicename restricted 

So let's say for example that we'd like to restrict our friend CoolSvc that we met before in this chapter from writing to anything but a file named c:\mystuff\coollog.txt. (Suppose also that CoolSvc runs in a svchost.exe instance under LocalSystem.) Step 1 in isolating CoolSvc involves restricting its SID; here's a sample run of doing that from an elevated command prompt:

 C:\>sc sidtype coolsvc restricted [SC] ChangeServiceConfig2 SUCCESS 

(Isn't sc.exe 's excitement whenever it makes something work downright infectious?)

Tip 

Again, we're changing a token's contents, so we've got to stop and start the svchost.exe to make the changes. And yes, I do mean the svchost.exe-if you've got other services sharing that svchost.exe, then you'll have to shut them all down, kill the svchost.exe from Task Manager, and then restart them, or just restart the whole system.

Granting Write Permissions to a Service SID

Clearly now that CoolSvc is a restricted service, it cannot use its LocalSystem SID to write anything, and so it's kind of useless at the moment. If it were to try to write to c:\mystuff\ coollog.txt, then NTFS would ask to see its credentials before allowing it to write. CoolSvc would brandish them, only to have NTFS respond "hmm, I see you have a LocalSystem SID, they're nice…oh, but I see that it's not usable for write operations. Sorry."

The service will need some help in order to write to c:\mystuff\coollog.txt. To accomplish that, recall that Vista's SCM creates a service SID for every service. To see that, look back to Figure 7.3 and you will see that that particular svchost.exe is a member of some groups that we've never heard of before: KtmRm, NlaSvc, TermService, and more. You may recognize those names: they're the names of the services inside that svchost.exe.

These SIDs aren't "complete" SIDs in that they're not separate accounts; they're just labels, sort of like Vista's integrity levels, the SIDs that look like Mandatory Label\Medium Level Label-there's no domain named "Mandatory Label," and no actual group or user account named NlaSvc. But they can, believe it or not, be specified on permissions for NTFS, the Registry, and the like.

For example, I can now right-click c:\mystuff\coollog.txt and open its Advanced security dialog, and then click "Add…" to create a new permission. It first asks me to choose a file, group, or whatever, but I want to grant a permission on that file to the CoolSvc Service, coolsvc. To see how I'd do that, look at Figure 7.4.

Figure 7.4: Specifying a service name for a permission

In that dialog box, you see how I've specified that I'd like to grant a permission on a file (the dialog doesn't show the file's name) to an account with a domain name of "NT Service" and a name of "coolsvc." Once I click OK, it takes Vista a second or two, but it soon realizes that yes, it does know of an SID for something called NT Service\coolsvc, and lets me create a permission allowing CoolSvc write access to the file.

Note 

Please remember that this is a cooked-up example. You don't have a CoolSvc on your system, and so won't be able to duplicate exactly what I've done-I've only done that to illustrate the point of how to give a service the permission to modify something.

Instead, by creating SIDs for every service, Vista makes it possible for you to create a permission on an NTFS volume, in the Registry or the like and name a particular service in that permission, enabling you to tell an object that it's okay for a particular Windows service to write to that object, even if nothing else can. At this point, CoolSvc can modify c:\mystuff\ coollog.txt, and nothing else.

Understanding the sc.exe Restricted SID Commands

Now that I've explained service isolation and how to make it work, let's look a bit further at what sc.exe can do to control service SIDs. As you saw before, you control service SIDs with the new Vista sc.exe “sidtype” command. Its full syntax looks like

 sc [servername] sidtype servicename none|unrestricted|restricted 

We've already seen what "restricted" does, or at least part of what it does. The full result of using restricted causes two things. First, your svchost.exe gets to use its service account SID for everything except writing, as you know. But the second effect of "restricted" is to tell SCM to put CoolSvc 's SID into its svchost.exe 's token. You can't tell Vista not to create a SID for CoolSvc as far as I know, but you can tell it whether or not to include the service's SID on the svchhost.exe 's token. You can tell SCM not to include the SID on the svchost.exe token with the "none" option, as in

 sc sidtype coolsvc none 

This also has the effect of unrestricting CoolSvc 's token. Alternatively, you could replace "none" with "unrestricted." In that case, the svchost.exe gets the SID in its token, but that SID is not restricted, and the svchost.exe has full use of its SID from LocalSystem, Network-Service, or LocalService.

To find a service SID's current state of none, restricted, or unrestricted, just type

 sc qsidtype servicename 

Or, to view a service's actual SID, type

 sc showsid servicename 

And remember to do those commands from an elevated command prompt. Reviewing what we discussed:

• A service always gets to use the SID of its service host.

• A service also gets an SID of its own.

• You (or a developer) can potentially take from a service the ability to use its service host's SID for any write operations with the "restricted" setting.

• If you do restrict a service, it is absolutely essential to remember to grant the service's service-specific SID write access to whatever it needs in order for the service to get its job done.

• Restart the whole svchost.exe to see the results of your changes.

What about the case where there is more than one service running in a particular service host? Well, if they're all set to either "none" or "unrestricted," then they'll run just fine. But if the services in a service host are mixed, with some restricted and some not, then the restricted ones will fail to start. The only way to use restricted services is to ensure that if one service in a service host is restricted, then all of the services in that service host are unrestricted.