Best practices and guidance for writers of service discretionary access control lists (914392)


The information in this article applies to:

  • Microsoft Windows Server 2003, Web Edition
  • Microsoft Windows Server 2003, Standard Edition
  • Microsoft Windows Server 2003, Enterprise Edition
  • Microsoft Windows Server 2003, Datacenter Edition
  • Microsoft Windows Server 2003, Standard x64 Edition
  • Microsoft Windows Server 2003, Enterprise x64 Edition
  • Microsoft Windows Server 2003, Enterprise Edition for Itanium-based Systems
  • Microsoft Windows Server 2003 SP1
  • Microsoft Windows XP Home Edition
  • Microsoft Windows XP Professional
  • Microsoft Windows XP Media Center Edition
  • Microsoft Windows XP Tablet PC Edition
  • Microsoft Windows XP Service Pack 1
  • Microsoft Windows XP Service Pack 1a
  • Microsoft Windows XP Service Pack 2
  • Microsoft Windows 2000 Professional
  • Microsoft Windows 2000 Server
  • Microsoft Windows 2000 Advanced Server
  • Microsoft Windows 2000 Datacenter Server

SUMMARY

Service discretionary access control lists (DACLs) are important components of workstation and of server security. This Microsoft Knowledge Base article describes how to interpret the DACLs on services. This article also provides best-practice guidance for writers of service DACLs when they are developing and assessing the security of their programs.

INTRODUCTION

You can use this Microsoft Knowledge Base article as a guide to help evaluate the security of service discretionary access control lists (DACLs).

MORE INFORMATION

To display the DACLs for a service, use the sc command together with the sdshow argument as shown in the following example, where service_name is the name of the service whose DACLs you want to display:

sc sdshow service_name

The command generates results that are similar to these:

(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;PU)(A;;CCDCLCSWLOCRRC;;;LS)

This sample output from the sc command shows a service's security description in the Security Descriptor Definition Language (SDDL) syntax. For information about the SDDL syntax, visit the following Microsoft Web site:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/security/security_descriptor_definition_language.asp

There are several things to look for to determine whether a service DACL is vulnerable. The following tables describe how to read the results of the sc command, how to interpret each permission string, and how to interpret to whom the permission is granted.

You can independently evaluate each string of characters that are enclosed in parentheses by using the following key:

(Allow/Deny;;String of permissions;;;SID or acronym for built-in account or group)

Each two-letter pair in the string of permissions corresponds to a specific right or permission:
Pair Right or permission
CCQueryConf
DCChangeConf
LCQueryStat
SWEnumDeps
RP Start
WPStop
DTPause
LOInterrogate
CRUserDefined
GAGenericAll
GXGenericExecute
GWGenericWrite
GRGenericRead
SDDel
RCRCtl
WDWDac
WOWOwn

Exercise the most caution with the ChangeConf (DC) permission. Look for the ChangeConf permission when you are determining whether your service is vulnerable to an elevation-of-privilege attack. This permission enables a designee to change the configuration of the service to include the binary file that is run when the service is started. You should also exercise extreme caution with the WDac (WD) and the WOwn (WO) permissions because both can be used to escalate permissions to LocalSystem. Make sure that these rights are not granted to a user who has low permissions. This table lists the codes that are used to identify the type of user that is granted access in the SDDL syntax.
CodeUser type
DADomain Administrators
DGDomain Guests
DUDomain Users
EDEnterprise Domain Controllers
DDDomain Controllers
DCDomain Computers
BABuilt-in (Local ) Administrators
BGBuilt-in (Local ) Guests
BUBuilt-in (Local ) Users
LALocal Administrator Account
LGLocal Guest Account
AOAccount Operators
BOBackup Operators
POPrinter Operators
SOServer Operators
AUAuthenticated Users
PSPersonal Self
COCreator Owner
CGCreator Group
SYLocal System
PUPower Users
WDEveryone (World)
REReplicator
IUInteractive Logon User
NUNetwork Logon User
SUService Logon User
RCRestricted Code
WRWrite Restricted Code
ANAnonymous Logon
SASchema Administrators
CACertificate Services Administrators
RSRemote Access Servers Group
EAEnterprise Administrators
PAGroup Policy Administrators
RUAlias to Allow Previous Windows 2000
LSLocal Service Account (for Services)
NSNetwork Service Account (for Services)
RDRemote Desktop Users (for Terminal Services)
NONetwork Configuration Operators
MUPerformance Monitor Users
LUPerformance Log Users
ISAnonymous Internet Users
CYCrypto Operators
OWOwner Rights SID
RMRMS Service

How to interpret a DACL string in SDDL format

This information describes how to interpret the sample DACL string that is listed at the top of this article. This interpretation lists each access control entry (ACE) individually.
  • (A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)

    This access control entry (ACE) gives LocalSystem (SY) the following rights:
    • QueryConf
    • ChangeConf
    • QueryStat
    • EnumDeps
    • Start
    • Stop
    • Pause
    • Interrogate
    • UserDefined
    • Delete
    • RCtl
    • WDac
    • WOwn
    The access control entry (ACE) is restricted to LocalSystem. This is good for security because LocalSystem is already the most powerful security context on the workstation. Therefore, there is no elevation risk.
  • (A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)

    This access control entry (ACE) applies to built-in local administrators (BA). This access control entry (ACE) gives the same rights as in the previous access control entry (ACE) to all the local administrators. This is also a very powerful security context on the workstation. Therefore, there is again no elevation risk.
  • (A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;AU)

    This access control entry (ACE) gives all the previous rights to any authenticated user (AU).
In the last access control entry (ACE), a user in a group that has low rights, such as any authenticated user, can change the configuration of the service. The configuration includes the binary file that is run when the service is started and the account under which the service is run.

The following sample DACL does not give ChangeConf rights to authenticated users:

(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPLOCRRC;;;PU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SO)(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;DT;;;LS)(A;;DT;;;NS)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;NO)


In this DACL, authenticated users (AU) are given only the following rights:
  • QueryConf
  • QueryStat
  • EnumDeps
  • Interrogate
  • UserDefined
  • RCtl
There are no potential risks of escalation via the Authenticated Users group with these rights granted. The Power Users (PU) group can already escalate to LocalSystem, so should not be considered an escalation risk. In this example, the Power Users group has all the same rights as the Authenticated Users group except that the Power Users group can also start the service (RP). The Local Administrators (BA) group is next. This group and the next group, the Server Operators (SO) group, both have ChangeConf, WDac, and WOwn permissions. This is acceptable because only the most-trusted users should be in the Local Administrators or the Server Operators group.

The LocalSystem (SY) group is given the same permissions as the Power Users group, but is also given Stop and Pause permissions. This seems to be appropriate. The next two short access control entries (ACEs) give the Local Service account and the Network Service account permissions to pause the service. This also seems to be appropriate because Local Service and Network Service are both powerful local accounts.

The Network Configuration Operators (NO) group, however, is given ChangeConf permissions. The Network Configuration Operators group was added in Windows XP to let trusted users change network settings without having full administrator permissions. By default, the Network Configuration Operators group is empty. The group is sometimes used to give network configuration permissions to specific users. For example, the owner of a portable computer might be given this permission. Users in the Network Configuration Operators group frequently have physical control of the computer. However, the intention of this group is not to give these users full administrator permissions. Therefore, this service DACL should not give ChangeConf permissions to the Network Configuration Operators group.

Best practices

Limit service DACLs to only those users who need a particular access type. Be especially cautious with the following rights. If these rights are granted to a user or to a group that has low rights, the rights can be used to elevate to LocalSystem on the computer:
  • ChangeConf (DC)
  • WDac (WD)
  • WOwn (WO)
For more information about access rights and permissions, visit the following Microsoft Web site:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/service_security_and_access_rights.asp

Modification Type:MinorLast Reviewed:2/28/2006
Keywords:kbinfo KB914392 kbAudITPRO kbAudDeveloper
©2004 Microsoft Corporation. All rights reserved.