Windows Vista Services
There is a lot of processing that goes on behind the scenes in a Windows Vista computer. When you print a document, a program in Windows has to handle the task of communicating between the application and the printer and getting the data delivered. When you first boot your computer and it needs to obtain an IP address from a DHCP server, a program in Windows handles the task of communicating with the DHCP server and configuring the network.
In fact, many of the functions that are inherent to Windows Vista, or that seem to just be a part of the operating system, are actually a small, separate program called a Service. Services in Windows Vista typically load before a user even logs in and continue running constantly in the background. They run within the context of svchost.exe, also known as ‘service host’.
Insert Token Here
Because Services typically start before a user has even logged in, they do not execute with the privileges of the logged-in user. Instead, the svchost.exe program runs in the context of one of the following system accounts: LocalSystem, LocalService or NetworkService. LocalService and NetworkService have always been too limited to pose a threat, but Services running under the powerful LocalSystem account make a good target for would-be attackers.
Prior to Vista, many Services received the LocalSystem privileges. The problem was that the LocalSystem account had virtually unlimited access to the local machine and network resources. With Vista, one of the big security measures was to protect running Services by providing them with the security token of either LocalService or NetworkService, both of which are severely limited compared with LocalSystem. Vista also includes tighter security restrictions to ensure that none of the three system accounts has access to sensitive files, folders or processes.
Controlling Services
The Services MMC is the applet traditionally used to manage and configure services in Windows. With the SCM, you can list the services on the computer, configure the services and establish whether they start automatically or not, and start, shut down or restart services.
The Services MMC is more or less a GUI interface for the sc.exe, the Service Control Manager, that really runs things. Past versions of Windows have not included the sc.exe program by default, but Vista does. Using sc.exe, you can script service management and control services from a command line prompt. When managing large networks, this can be much more efficient.
Locking Down Services
With Windows Vista, Microsoft has made some significant changes and improvements in the way services are protected and secured. Because of the way that services have traditionally executed with the privileges of the LocalSystem account, security experts have recommended various steps for trying to protect systems from an attacker exploiting those services.
Shutting off all unnecessary services, manually replacing the LocalSystem account with a less-powerful account to run the services, and changing file and folder permissions to restrict the ability of the system accounts to alter or damage the system are some common recommendations for protecting services in prior versions of Windows.
New Services Security in Vista
In Vista, Microsoft has included three major changes that will make Services more secure: session separation, reducing the privileges of the services and service isolation. Below we will take a look at each of these functions.
Session Separation
Windows has used sessions for some time to separate instances of Windows. On systems where multiple users share the computer or where Terminal Services or Remote Desktop was in use, it is possible to have a number of active sessions running.
With Vista, Microsoft executes the Services in the context of Session 0, the initial session created before anyone even logs in to Windows. Session 0 does not have a user interface or any way to interact with the video hardware at all. It also cannot be used to leverage the privileges of the logged-in user to execute malicious code. Keeping Services in Session 0 protects Vista from a variety of the security concerns from past versions of Windows.
Reduced Service Privileges
Vista uses the functionality of the security tokens and the ability to limit, or filter, the privileges of the tokens, to provide better security for Services in Vista. Vista runs multiple services under a single instance of svchost.exe, so there is some behind-the-scenes stuff that goes on in order to determine what privileges the svchost.exe token should be granted.
Basically, a Developer can reduce Service privileges within program code or an Administrator can reduce Service privileges from a command line. In any event, svchost.exe will only receive the privileges that are necessary for the services that are running under it. If svchost.exe has a number of services and some do not declare the privileges they need, the SCM will copy the service account’s token and use that for svchost.exe’s privileges.
Service Isolation
Microsoft grants each Service its own SID, a Service SID, which can be used to uniquely identify and restrict them. Vista can be configured to allow a Service to write to an object only if its Service SID is specifically granted authority for that action.
Either Developers or Administrators can control and restrict the functionality of Services based on the Service SID. By isolating each service with a unique SID, Vista provides much greater flexibility for managing and restricting the privileges of the individual Services.
More Secure Services
Services have long been a target of attackers and a sore spot for security administrators. Programs that run automatically before a user is even logged in, and run in the context of a powerful system account with pervasive privileges, are not great for system security.
By separating the Services into their own sessions, providing the ability to reduce the privileges of individual services, and assigning unique SID’s that can be used to control and restrict individual services, Microsoft has provided many more tools to allow developers and administrators to ensure that Services are not the Achilles heel of the system.
