Service Enhancements in Windows 7

The implementation of services in Windows 7 builds on improvements previously made in this area in Windows Vista. The following list summarizes some of the changes to services that were implemented in Windows Vista to enhance the security, reliability, and performance of services as they run on the system.

• Running with least privileges Enhances security by removing unnecessary privileges from the process token under which the service runs. For stand-alone services, SCM does this by checking the list of required privileges against the process token and removing any unnecessary privileges. A service can be configured with required privileges; this is typically a service designer action as opposed to an administrator action because the list of required privileges is tied to the service design. SCM strips unnecessary privileges present in the service's account before starting the service process. If the service process hosts multiple services, SCM computes the union of the required privileges of all hosted services and strips unnecessary privileges. By default, no privilege stripping is performed, thus pre-Windows Vista services running on Windows Vista are not affected by this feature.
• Service isolation Uses restricted security identifiers (SIDs) to enhance security by allowing services to run with fewer privileges while still maintaining access to objects, such as registry keys, that are configured to allow access only to administrators. In earlier versions of Windows, many services are configured to run under the powerful LocalSystem account because the resources that they need to access are secured using ACLs for LocalSystem access (because it is worrisome to allow access to any less-privileged process). Running under the LocalSystem account causes security vulnerabilities in the service code to have a huge impact, however. In Windows Vista (similar to earlier versions of Windows), services can be configured to run under less-privileged accounts. However, only in Windows Vista can the service designer configure the service to have a unique SID added to the process token (called the service SID) and use ACLs to secure the resources used by the service (registry keys, for example) to allow full access by the service SID alone. This keeps the service account at a lower privilege level yet allows only the service process access to the resources, as opposed to any process running the service account accessing the resources.
• Restricted service SID If the service designer chooses this option, the service SID is added to the process token at service process startup as in the service SID case. (In the case of a shared process, the SID is in a disabled state until the service starts.) In addition, the process token is marked Write Restricted, meaning that the service process code can write only to those resources explicitly secured with ACLs for the service SID. For example, consider a registry key that allows full access to the LocalService account. A restricted service process would not get Write access to that key even if it were running under the LocalService account. The restricted service would get access only if the key were secured with ACLs to allow the service SID to be written to. This feature is intended to mitigate the damage that a service can do to the system if it is exploited. Typically, these features are implemented by the service designer, not the administrator.
• Restricted network access Uses Windows Service Hardening (WSH) and per-service SIDs to enhance security by restricting access by a service to network resources, such as ports and protocols.
• Session 0 isolation Enhances security by isolating services from user applications by running all services in Session 0 while user applications are required to run in Session 1 or higher. This means that a service that is marked as Interactive in earlier versions of Windows and can show a UI will no longer be able to show a UI in Windows Vista. Note that such services are already broken in previous versions of Windows with the introduction of Fast User Switching (FUS). Such services are expected to run a UI process in the user's session, which can throw the UI and communicate with the service using COM or Remote Procedure Call (RPC).
• Delayed Start A new service startup type that enhances performance immediately after startup by allowing startup of less-critical services to be delayed until approximately 2 minutes after Windows has started. This feature enables Windows and applications to be usable sooner after startup. An example of a service that is configured for Delayed Start is the Windows Update service.
• Service state change notifications Enhances performance by enabling SCM to detect when a service has been created or deleted or has changed its status without having to poll the status of the service. SCM can then notify the client of the change of status of the service. This feature works for local as well as remote clients.
• Preshutdown notifications Enhances reliability by allowing SCM to notify services in advance of shutdown so that they have more time to clean up and shut down gracefully. In earlier versions of Windows and in Windows Vista as well, the computer shutdown has a fixed time limit by default. Although most services are unaffected by this, some services can have a dirty shutdown, which can cause long delays in starting up during the next boot (for example, a database recovery after a dirty shutdown might be quite time consuming). In Windows Vista, such services can subscribe to preshutdown notifications. The system will send this notification after all users are logged off and before the computer shutdown is initiated. The services can take up as much time as they want before they stop. However, this can affect shutdown time negatively and has to be considered by the service designer. Again, this is a feature for the service designer to implement-it cannot be configured by the administrator.
• Shutdown ordering Enhances reliability by allowing service owners to specify dependencies between services in a global dependency list to control the shutdown order for services. This is applicable only for services that subscribe to preshutdown notifications. In this case, such services can experience either an ordered or unordered shutdown. If the services add themselves to the ordered list in the registry, SCM will wait for the service to stop before proceeding to shut down the next service in the list. After ordered preshutdown is complete, unordered preshutdown begins. Note that the computer shutdown ordering of services is arbitrary, as described previously.
• Detection of and recovery from nonfatal errors Enhances reliability by allowing SCM to detect nonfatal errors with services, such as memory leaks, and initiate specified recovery actions. In earlier versions of Windows, only allowed services could be configured with recovery actions (restart, run a script, and so on) when the process crashed. In Windows Vista, in addition, services can be configured to have recovery actions initiated if they stop with an error as opposed to crashing. Therefore, services can recover from memory leaks and other issues by using this feature.
• Stop reason An administrator that stops a service can now specify the reason for stopping the service. This allows postmortem reliability analysis to find out why a service is failing. If the administrator specifies the stop reason using the Sc.exe stop option, SCM logs an event with the stop reason to the event log. A new API called ControlServiceEx has also been added to accept the stop reason.
• Localization A service designer now can configure a service property, such as a display name or description, as a localizable string and have SCM load the specified resource from a resource DLL when a user queries the service property. The name is in the form @resource_dll,-resource_ID.

Windows 7 introduces additional enhancements to how services are implemented to increase the security, performance, and energy efficiency of Windows computers. These enhancements include the following:

• New unified architecture Windows 7 has a new unified architecture that drives the scheduling of background processes (services and scheduled tasks) on Windows. This is transparent to users, IT professionals, and existing APIs, and it enables trigger-starting services as described next.
• Trigger Start Windows 7 now allows the starting or stopping (but not pausing or resuming) of a service when a specific event, known as a trigger, occurs. Examples of triggers that can be used to start or stop a service can include the following:
  • First IP address arrival
  • Last IP address departure
  • Connecting or disconnecting a hardware device
  • Joining or leaving a domain
  • Group Policy change
  • Custom triggers raised from either kernel or user mode
  For example, connecting a scanner to a Windows 7 computer can trigger the start of the imaging service used by the device. Disconnecting the scanner can also trigger the stopping of the service. Trigger Start improves the performance of Windows by reducing the number of running services on the computer. It also enhances security because having fewer running services means there is less attack surface. Finally, Trigger Start can improve boot performance by reducing the number of services that need to be started when Windows is started. For a complete list of triggers, see http://msdn.microsoft.com/en-us/library/dd405512.aspx.
• New Sc.exe command options The Sc.exe command-line tool for managing services has been enhanced in Windows 7 with new command options for managing service triggers, including the following:
  • qtriggerinfo Queries the trigger parameters of a service
  • triggerinfo Configures the trigger parameters of a service
• Managed service accounts Managed service accounts in Windows Server 2008 R2 and Windows 7 are managed domain accounts that provide the following features to simplify service administration:
  • Automatic password management
  • Simplified service principal name (SPN) management, including delegation of management to other administrators
• Virtual accounts Virtual accounts in Windows Server 2008 R2 and Windows 7 are "managed local accounts" that provide the following features to simplify service administration:
  • No password management is required
  • The ability to access the network with a computer identity in a domain environment