Low-Privilege Service Accounts in Windows XP and Windows .NET Server

Traditionally, Windows services have had the choice of running under either the local system security context or under some arbitrary user account. Creating user accounts for each service is unwieldy at best. Because of this, nearly all local services are configured to run as SYSTEM. The problem with this is that the local system account is highly privileged TCB, SYSTEM SID, and Local Administrators SID, among others and breaking into the service is often an easy way to achieve a privilege elevation attack.

Many services don t need an elevated privilege level; hence the need for a lower privilege level security context available on all systems. Windows XP introduces two new service accounts:

The local service account (NT AUTHORITY\LocalService)
The network service account (NT AUTHORITY\NetworkService)

The local service account has minimal privileges on the computer and acts as the anonymous user account when accessing network-based resources. The network service account also has minimal privileges on the computer; however, it acts as the computer account when accessing network-based resources.

For example, if your service runs on a computer named BlakeLaptop as the local Service account and accesses, say, a file on a remote computer, you ll see the anonymous user account (not to be confused with the guest account) attempt to access the resource. In many cases, unauthenticated access (that is, anonymous access) is disallowed, and the request for the network-based file will fail. If your service runs as the network service account on BlakeLaptop and accesses the same file on the same remote computer, you ll see an account named BLAKELAPTOP$ attempt to access the file.


	Remember that in Windows 2000 and later a computer in a domain is an authenticated entity, and its name is the machine name with a $ appended. You can use ACLs to allow and disallow computers access to your resources just as you can allow and disallow normal users access.

Table 5-6 shows which privileges are associated with each service account.

Table 5-6 Well-Known Service Accounts and Their Privileges
Privilege	Local System	Local Service	Network Service
SeCreateTokenPrivilege	X
SeAssignPrimaryTokenPrivilege	X
SeLockMemoryPrivilege	X
SeIncreaseQuotaPrivilege	X
SeMachineAccountPrivilege
SeTcbPrivilege	X
SeSecurityPrivilege	X
SeTakeOwnershipPrivilege	X
SeLoadDriverPrivilege	X
SeSystemProfilePrivilege
SeSystemtimePrivilege	X	X	X
SeProfileSingleProcessPrivilege	X
SeIncreaseBasePriorityPrivilege	X
SeCreatePagefilePrivilege	X
SeCreatePermanentPrivilege	X
SeBackupPrivilege	X
SeRestorePrivilege	X
SeShutdownPrivilege	X
SeDebugPrivilege	X
SeAuditPrivilege	X	X	X
SeSystemEnvironmentPrivilege	X
SeChangeNotifyPrivilege	X	X	X
SeRemoteShutdownPrivilege
SeUndockPrivilege	X	X	X
SeSyncAgentPrivilege
SeEnableDelegationPrivilege

As you can see, the local system account is bristling with privileges, some of which you will not need for your service to run. So why use this account? Remember that the big difference between the two new service accounts is that the network service account can access networked resources as the computer identity. The local service account can access networked resources as the anonymous user account, which, in secure environments where anonymous access is disallowed, will fail.


	If your service currently runs as the local system account, perform the analysis outlined in A Process for Determining Appropriate Privilege earlier in this chapter and consider moving the service account to the less-privileged network service or local service accounts.