Anda di halaman 1dari 5

Basic Training

Editors: Richard Ford, Michael Howard,

Common Permissions in Microsoft Windows Server 2008 and Windows Vista

nlike the relatively simple User:Group: World structure originally implemented in Unix, the permission model in Windows is rich and suffers the associated cursecomplexity.

Its easy to make choices that have undesirable implications.

In this article, Ill provide a brief overview of Windows permissions, common security problems associated with them, and guidance on avoiding these security issues. Lets first look at the most common security problems associated with permission grants in Windows: The system assumes that applications are installed into Program Files, which have a safe default set of permissions. If an application is installed into a nondefault locationfor example, C:\WizAppFooand the application installer doesnt reset the permissions appropriately, users will be able to modify the executable and its settings. This allows attacks against all users who use the application. If user A can write an executable and convince user C to run it, user A might be able to compromise user C. This is particularly serious if user C is the system administrator. If all users can modify an object by default, we have what could be called a collaborative Access Control List (ACL). We can also

view this as a mutual tampering ACL as the object in question is subject to any users modification. Such an ACL is used in parts of the client file system to enable popular usage scenarios.

Objects and their security descriptors

All named objects in Windows have security descriptors that provide information concerning their owner, as well as list which subjects have or are denied specified permissions and (optionally) specify which accesses must be logged to the system event log for specific subjects. The specification of what a subject can do to an object or resource in question is implemented in the ACLs Access Control Entry (ACE) data structures. These enumerate who (which subject) has what access to which objects. There are a number of different objects of interest, including files, directories, registry keys, services, proc esses, threads, and named pipes. Whenever an object is accessed, the security descriptor and the users token (a privileged data structure associated with the user

that specifies the users identity and group memberships) are input to the systems permission checking routine to determine if access is allowed. Two basic types of ACL exist: discretionary ACLs (DACLs) and mandatory ACLs. (An excellent discussion of mandatory access control (MAC) systems and security policy can be found in Security Engineering, by Ross Anderson (Wiley Computer Publishing, 2001, chapter 7). Although the owner of a file controlled by a DACL can change access rights associated with the file, this isnt allowed in MAC systems. NT-based Windows systems support DACLs and an attribute known as the System ACL (SACL), which specifies which actions on the object by what subjects are to be logged to the security event log. Given that only administrators or the system can change a SACL, its not a DACL, but it wasnt used as a MAC label. With Windows Server 2008 and Windows Vista, the SACL has been extended to carry integrity level information and is in the process of being converted to something like a MAC label. This provides the basis for Microsofts steps toward MAClike functionality in Windows Server 2008 and Windows Vista, in which a no-read-down policy has been introduced. The integrity label is used to establish the low label that marks the Internet Explorer process used in low rights

John R. Michener Microsoft

Published by the IEEE Computer Society 1540-7993/07/$25.00 2007 IEEE IEEE Security & Privacy


Basic Training

Table 1. ACE_types for files and directories.


Table 2. ACE_types for files and directories.


an ACL with no ACEs in it is an empty DACL. Because an ACE grants a specified subject access to the object in question, no one can access an object with an empty DACL. Do not set either! Dacl_flags are security descriptor flags that apply to the DACL. The dacl_flags string can be a concatenation of zero or more of the following strings: P. This is the protected flag. The permissions being declared are the only ones extant, and other permissions from higher up the inheritance tree dont apply. This is a control flag. AI. ACEs are inherited using the NT5 inheritance mechanism, where ACE entries are automatically propagated from parent to children for securable objects that support the inheritance model (such as the file system, registry, and active directory). The modern APIs for setting DACLs set this automatically. This is an informational flag. AR. This legacy, NT4 file system autoinherit required flag was set to indicate that the inheritance of entries from parent to child is required. Modern APIs for setting DACLs will write only AI.
Sacl_flags are security descrip-

Internet Explorer. System and high labels help protect critical system resources.

Object security descriptors

The security descriptor binary data structure is mapped to the Security Descriptor String Format to provide a somewhat human-readable text representation. A string format security descriptor is represented as a null-terminated string with tokens to indicate each of the four main components: owner (O:), primary group (G:), DACL (D:), and SACL (S:), where these are defined as O: owner_sid: A security identifier (SID) string that identifies the objects security principal. G: group_sid: A SID string that identifies the objects primary group. D: dacl_flags (string_ace_1) (string_ace_2)... (string_ace_n): An ordered listing of permission denies and grants, denies first. S: sacl_flags (string_ace_1)(string_ ace_2)... (string_ace_n): A listing of integrity information and audit event specifications. An object without a DACL is said to have a null DACL. Objects with null DACLs havent been secured, and anyone can control them. At the other extreme,
IEEE Security & Privacy May/June 2008

tor control flags that apply to the SACL. The sacl_flags string uses the same flags as the dacl_ flags string. The string_aces are ACEs expressed in a human readable string format that explicitly grant or deny permissions in the DACL and set policy in the SACL. Each string_ace is enclosed in parentheses ( ) and has the following structure: (ace_
type;ace_flags;rights; object_guid;inherit _object_guid;account _sid). You can read more about

their structure at http://msdn2. y/ aa374928(VS.85).aspx.

Not all possible components of the security descriptor need be present. If not explicitly specified at creation time, the owner field of the security descriptor is set to the SID of the principal invoking the object creation. The group field is set to the primary group of the users security token. If it isnt necessary to audit an object or to set an integrity flag, the SACL wont be present. Within the string_aces, only those fields that are necessary are included (the minimal set is ace_type, rights, and the subject, typically the account_sid). The ace_flags field is included if its necessary to control inheritance. Unless specifically declared, an objects creator is its owner. Each object can have only one owner and one primary group, but the DACL and SACL can have many sub-components declaring the appropriate access, restrictions, and system settings for various principals. The primary group is present only to support the Posix subsystem. The typical default grant of full control to an object owner creates unanticipated security issues. A users token contains their identity as well as the various groups of which theyre members. Unlike the behavior for members of the built-in administrators group (BA), in which object ownership is associated with BA, if a member of one of the administrative groups, such as network operators or backup operators, created a number of objects, ownership was associated with their identity. If that user later left the administrative group in question, their continued ownership allowed inappropriate access These security issues are now mitigated by the Owner Access Restriction ACL, which was introduced with Windows Vista and Server 2008. It allows the explicit declaration of what rights should be associated with ownership.

Basic Training

Lets look at the security descriptor for the root of a Windows Server 2008 system. Running the windows function cacls from the command line with the /S flag causes cacls to return results in standard SDDL: C:\>cacls c:\ /s c:\ D:PAI(A;OICI;FA;;;SY)(A;O ICI;FA;;;BA)(A;OICI;0x1200a9;;; BU)(A;CI;LC;;;BU)(A;CIIO;DC;; ;BU)(A;OICIIO;GA;;;CO) We can see that no ownership or group membership is claimed, and that the descriptor is a DACL due to the leading D:. The DACL is protected: the P and the NT5 informational flag is set. There are also several ace_strings.

3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +---------------+---------------+-------------------------------+ |G|G|G|G|Res'd|A| StandardRights| SpecificRights | |R|W|E|A| |S| | | +-+-------------+---------------+-------------------------------+ Figure 1. Mapping from ACE bit mask to ACE rights.

Table 3. Generic rights for files and directories.

0x10000000L 0x20000000L GENERIC_RIGHTS GA GenericAll, GenericFileAll, GenericKeyAll The caller can perform all normal operations on the object. GX GenericExecute, GenericFileExecute, GenericKeyExecute The caller can execute the object. (Note that this generally only makes sense for certain kinds of objects, such as file objects and section objects.) GW GenericWrite, GenericFileWrite, GenericKeyWrite The caller can perform normal write operations on the object. GR GenericRead, GenericFileRead, GenericKeyRead The caller can perform normal read operations on the object.

0x40000000L 0x80000000L

Understanding security descriptor string_aces

Table 4. Standard rights for files and directories.

0x00010000L 0x00020000L STANDARD_RIGHTS SD DELETE The caller can delete the object RC READ_CONTROL The right to read the information in the objects security descriptor, not including the information in the SACL STANDARD_RIGHTS_READ Standard specific rights that correspond to GENERIC_READ STANDARD_RIGHTS_WRITE Standard specific rights that correspond to GENERIC_WRITE STANDARD_RIGHTS_EXECUTE Standard specific rights that correspond to GENERIC_EXECUTE WD WRITE_DAC The caller can change the discretionary access control list (DACL) information for the object WO WRITE_OWNER The caller can change the ownership information for the object SYNCHRONIZE The right to use the object for synchronization. This enables a thread to wait until the object is in the signaled state. Not all object types support this access right.

Table 1 shows the ace_types relevant to files and directories. Table 2 shows the ace_flags relevant to our example concerning files and directories. The ace_flags for inheritance are the ruling factors for the inheritance of ACEs. ACE rights are denoted by a string that can be a hexadecimal representation, such as 0x7800003F, or a concatenation of rights strings, such as CCLCSWLOCRRC. Figure 1 shows the binary rights mapping for the ACE Access Mask. The system uses a single bitmap representation of ACE rights for all objects. Not all (and in some cases many) bits are meaningful for various objects. Only rights that are appropriate for an object are applied. Standard rights are those rights that are common to all securable objects. Generic rights are a convenient shorthand for specifying rights of similar intent for various objects. Specification of generic rights is mapped into the appropriate set of specific rights. Integrity labels are also encoded using the ACE rights field when specifying the SACL.

0x00020000L 0x00020000L 0x00020000L 0x00040000L

0x00080000L 0x00100000L

Table 3 lists the available generic rights for files and directories, and Table 4 lists the available standard rights for files and directories. Several largely equivalent rights mappings are used rather indiscriminately. Full Control is equiv-

alent to Generic_All (GA). For the file system, File All (FA) is the appropriate full control declaration. Key All (KA) is the appropriate full control declaration for the registry. SDDL expressions frequently mix these terms.
65 IEEE Security & Privacy

Basic Training

Table 5. Specific rights for files and directories.

Specific Rights 0x00000001 0x00000002 0x00000004 0x00000008 0x00000010 0x00000020 0x00000040 Files CC DC LC SW RP WP DT Read Write Append ReadEA (Read Extended Attributes. Extended attributes are application defined metadata) WriteEA Execute Delete child (This is meaningless for files since to delete an object you need SD on the object or DT on its parent container.) Directory CC DC LC SW RP WP DT List AddFile AddSubDir ReadEA WriteEA Traverse Delete Childt

Table 5 shows the specific rights associated with files and directories.1 The Object_guid holds the globally unique identifier (guid) of the object being permissioned and the Inherit_object_guid holds the guid of the object from which it inherits permissions, and theyre used in specifying the security of objects in Active Directory. The file system or registry typically doesnt use them. The ACE structures account _sid field denotes the security principal thats granted or denied the access rights specified in the ACE. The field might hold a SID or a shorthand SID string notation for a common account. This notation is used wherever possible to make the system more readable. A list of well-known accounts is provided elsewhere.1

are granted inheritable File All over both files (due to the object inherit) and directories (due to the container inherit). Creator/owner (CO) is granted Generic_All, which maps to File All, over both files and directories below the root directory (due to the inherit-only flag). The grant to built-in user (BU) is more interesting. The first string_ace applies to both files and directories in the root and below and allows List, Read, ReadEA, Traverse, Execute, ReadAttr, ReadControl, and Sync. The second string_ace allows AddSubDir in the root and below (due to the IO InheritOnly flag), and the third string_ace allows AddFile in the directories below the root.

Access checking
When the system determines if a user or principal is allowed to perform an operation on an object, it checks several things: the users privileges and token, and the objects security descriptor. An objects binary security descriptor passes to the AccessCheck routine with the users token. A requested access mask bit vector is prepared, representing the access rights that must be granted for access check to succeed. The access check process is then run: the security system examines the users security token and considers the users privileges (typically due to role/membership, such as administrator) in combination with the requested access and

Interpreting security descriptor string_aces

Rephrasing the output from running cacls on the root of the system drive: D:PAI (A;OICI;FA;;;SY) (A;OICI;FA;;;BA) (A;OICI;0x1200a9;;;BU)(A;CI;L C;;;BU)(A;CIIO;DC;;;BU) (A;OICIIO;GA;;;CO) This is a protected DACL with the auto-inherit flag for modern file systems set. BA and system (SY)
IEEE Security & Privacy May/June 2008

the DACL on the object. If the object has a null DACL, the system grants access. It also grants access if the access the user requests is fulfilled by the users privileges. Otherwise, the DACL ACEs are examined in order. As soon as the security system can show that all requested access components are allowed, or any of the requested access components is denied, the security system returns a success in the former case and a failure in the latter case. Thus, the DACLs list of ACEs must be ordered so that deny ACEs are at the front of the list.1,2 Modern Windows tools order components in the security descriptor correctly, as do the appropriate modern Windows security functions (SetSecurityInfo and SetNamedSecurityInfo), but they wont reorder noncanonical security descriptors. Some of the older Windows functions didnt preserve the proper ordering of security descriptor components (such as AddAccessAllowedAce).

Windows resource protection

A change from earlier OS releases was a decision to protect OS files from inadvertent damage from the system administrator. To do this, Microsoft introduced a new protected entity, Trusted Installer. Control over system files and folders is associated with Trusted Installer, which installs the system files and folders. This provides a

Basic Training

reliability protection for the system. (Because the administrator has the TakeOwnership privilege, a determined administrator can circumvent this mechanism. This is why this is a reliability measure and not a security measure).

Setting safe file system permissions

The basic rule when setting DACLs is that you dont want administrators or other users executing code users wrote. If an application is to be installed, its wisest to install this to the default Program Files location. The default ACLs for this location give full control to Administrator and Local System and read and execute to users, which is appropriate. If an application is installed to some other location, or the installer lets the user choose their preferred location for an application, theres a potential problem: the default ACLs for other drives and for nonsystem or nonapplication areas of the system drive arent secure enough. In such cases, folders in which the application is installed must be ACLd with the appropriate, protected DACLs. The simplest and safest choice for installing an application is to duplicate the security settings on the Program Files folder. If this isnt done, set the DACL so that nonadministrators may not change DACLs or change Ownership of executables and may not write, append, or delete files in directories containing executables. The CO can be granted full control. Although folders in trusted areas (such as Windows, Program Files) typically dont allow user write, there are subfolders where this must be allowedfor example, folders holding error logs. If the executable is running under the users credentials and has to log an error, it needs write/append access to the error log/logging folder. We find the same issues in the registry, in which error information

is frequently stored in specified machine registry keys by a process running with user permissions. The proper approach in such cases is to not mix user writeable files with executable files. Use separate directories for files that must be trusted, such as executables, and files that must not be trusted (anything potentially written by an untrusted user). ACL the directories appropriatelyadministrator control over the executables and no administrator execute over folders with user writeable files.

Windows stores much of its state information in the Windows Registry. Registry data stores are known as hives, in which data is stored in keys and subkeys, which are both viewed as containers (subkeys arent viewed as objects, thus inheritance is controlled by the Container Inherit (CI) ace_flag specification). User-specific data is stored in the appropriate user section of hive key users, HKEY_USERS. As we would expect, appropriate users can write much of this data. In any session, Hive Key Current User, HKCU, points to the appropriate section of HKEY_USERS. System and machine information is stored in the Local Machine key hive, HKLM. Included in the information in HKLM is information for all the various system services. This information should be stored in SubKeys, either in the service key, or in a key under the service key. The service key must not be ACLd to enable the service to have SetKey (or the WDac or WOwn, which would enable such an attack) over itself, given that this allows the service to point to a different executable. Applications also store state information in their registry keys, which for machine-wide software will be in HKLM\Software. The general guidance for DA-

Managing the registry and its permissions

CLs for HKLM is that they must not let users write or modify this data or the associated ACLs and Ownershipwith an exception for error logging. In such cases, create separate keys for such information and ACL them appropriately. Thus the sensitive information can be ACLd to trusted subjects, and the logging data can be user writeable, as needed. The issue were trying to avoid is a user modifying trusted parameters (such as turning antivirus or antimalware services off ) or tampering with a link to an executable: The link between the installed executable and the icon that the user uses to invoke it is stored in the registry. If the attacker can modify this link, which is a pointer stored as a pathname to the executable, the attacker can cause a different file to load.

he capabilities of Microsofts ACL model in modern Windows systems allows fine grained control of object permissions. Ongoing tuning of permissions to deal with changing priorities and new issues should be expected. Similarly, enhancements in management tools to enable administrators to better manage system permissions are under development.
References 1. J. Michener, Understanding and Setting File and Registry Permissions in Modern Microsoft Operating Systems: Windows Server 2008, Windows Vista, MSDN TechNet, to appear. 2. M.E. Russinovich and D.A. Solomon, Microsoft Windows Internals 4th ed., Microsoft Press, 2005, pp. 506515.
John R. Michener is a senior security program manager at Microsoft. He has a PhD in mechanical engineering from the University of Rochester. Michener is a member of the IEEE, the ACM, and AAAS. Contact him at jrmichener@ IEEE Security & Privacy