|< Windows Access Control Programming 1 | Main | Windows Access Control Programming 3 >|Site Index |Download |

---

 

 

 

 

MODULE H1

WINDOWS OS SECURITY

::ACCESS CONTROL STORY::

PART 2

 

 

 

 

What are in this Module?

1. Access Control Lists (ACLs)

2. Object-specific ACEs

3. Trustees

4. Access Rights and Access Masks

5. ACCESS_MASK

6. Access Mask format

7. Generic Access Rights

8. Standard Access Rights

9. SACL Access Right

10. Directory Services Access Rights

11. How Security Descriptors are Set on New Directory Objects

12. Default Security Descriptor

 

 

 

 

 

 

 

 

My Training Period: cc hours. This is continuation fromWindows Access Control Programming 1. Before you begin, read someinstruction here.

 

 

The abilities for this session:

• Able to understand terms and their meanings used.

• Able to understand Windows Access Token, Securable Object and Security Descriptor.

• Able to understand Trustee and Security Identifier (SID).

• Able to understand Discretionary Access Control List (DACL) & Security Access Control List (SACL).

• Able to understand Access Control List (ACL), Access Control Entry (ACE) and their components.

• Able to understand the overall of Windows OSes security implementation through Access Control Model.

• Able to understand Right and Privileges in Windows.

• Able to understand access control functions used to manipulate the above mentioned items.

• Able to gather and understand the required information in order to use access control functions.

 

Access Control Lists (ACLs)   An ACL is a list of ACE.  Each ACE in an ACL identifies a trustee and specifies the access rights allowed,denied, or audited for that trustee.  The security descriptor for a securable object can contain two types of ACLs:   Discretionary Access Control List (DACL). Security Access Control List (SACL).   A DACL identifies the trustees that are allowed or denied access to a securable object.  When a process tries to access a securable object, the system checks the ACEs in the object's DACL to determine whether to grant access to it.   The system checks the ACEs in sequence until it finds one or more ACEs that allow all the requested access rights, or until any of the requested access rights are denied. If the object does not have a DACL, the system grants full access to everyone. If the object's DACL has no ACEs, the systemdenies all attempts to access the object because the DACL does not allow any access rights.   Each ACE specifies the types of access attempts by a specified trustee that cause the system to generate a record in the security event log.  An ACE in a SACL can generate audit records when an access attempt fails, when it succeeds, or both.  In future releases, a SACL will also be able toraise an alarm when an unauthorized user attempts to gain access to an object.  ACLs also provide access control to Microsoft® Active Directory® directory service objects.  Active Directory Service Interfaces (ADSI) include routines to create and modify the contents of these ACLs.   Access Control Entries (ACEs)   An ACE is an element in an ACL.  An ACL can have zero or more ACEs.  Each ACE controls or monitors access to an object by a specified trustee.  There are six types of ACEs, three of which are supported by all securable objects.  The other three types are Object-specific ACEs supported by directory service objects.  All types of ACEs contain the following access control information: A SID that identifies the trustee to which the ACE applies. An access mask that specifies the access rights controlled by the ACE. A flag that indicates the type of ACE. A set of bit flags that determine whether child containers or objects can inherit the ACE from the primary object to which the ACL is attached.

The following table lists the three ACE types supported by all securable objects.

 

 

System-alarm object ACEs are not currently supported.

 

Object-specific ACEs

 

Object-specific ACEs are supported for directory service (DS) objects.  An object-specific ACE contains a pair of globally unique identifiers (GUIDs) that expand the ways in which the ACE can protect an object.

 

 

Three types of object-specific ACEs are supported.  System-alarm object ACEs are not currently supported.

 

 

Any ACL that contains an object-specific ACE must use the revision ACL_REVISION_DS.

 

Trustees

 

A trustee is the user account, group account, or logon session to which an ACE applies.  Each ACE in an ACL has one SID that identifies a trustee.  User accounts include accounts thathuman users or programs such as Windows Services use to log on to the local computer.  Group accounts cannot be used to log on to a computer, but they are useful in ACEs to allow or deny a set of access rights to one or more user accounts.  A logon SID that identifies the current logon session is useful to allow or deny access rights only until the user logs off.  A logon SID is a SID that identifies a logon session.  You can use the logon SID in a DACL to control access during a logon session.  A logon SID is valid until the user logs off.  A logon SID is unique while the computer is running; no other logon session will have the same logon SID.  However, the set of possible logon SIDs is reset when the computer starts up.  To retrieve the logon SID from an access token, call theGetTokenInformation() function for TokenGroups.  The access control functions use theTRUSTEE structure to identify a trustee.  TheTRUSTEE structure enables you to use a name string or a SID to identify a trustee.  If you use a name, the functions that create an ACE from theTRUSTEE structure perform the task of allocating the SID buffers and looking up the SID that corresponds to the account name.  There are two helper functions,BuildTrusteeWithSid() and BuildTrusteeWithName(), that initialize a TRUSTEE structure with a specified SID or name.BuildTrusteeWithObjectsAndSid() and BuildTrusteeWithObjectsAndName() allow you to initialize a TRUSTEE structure with object-specific ACE information.  Three other helper functions, GetTrusteeForm(),GetTrusteeName(), andGetTrusteeType(), retrieve the values of the various members of aTRUSTEE structure.  The ptstrName member of the TRUSTEE structure can be a pointer to an OBJECTS_AND_NAME or OBJECTS_AND_SID structure.  These structures specify information about an object-specific ACE in addition to a trustee name or SID.  This enables functions such as SetEntriesInAcl() and GetExplicitEntriesFromAcl() to store object-specific ACE information in theTrustee member of theEXPLICIT_ACCESS structure.

 

Access Rights and Access Masks

 

An access right is a bit flag that corresponds to a particular set of operations that a thread can perform on a securable object.  For example, a registry key has theKEY_SET_VALUE access right, which corresponds to the ability of a thread to set a value under the key.  If a thread tries to perform an operation on an object, but does not have the necessary access right to the object, the system does not carry out the operation.  An access mask is a 32-bit value whose bits correspond to the access rights supported by an object.

 

ACCESS_MASK

 

The ACCESS_MASKdata type is a double word value that defines standard, specific, and generic rights. These rights are used in ACEs and are the primary means of specifying the requested or granted access to an object.

typedef DWORD ACCESS_MASK;

Access Mask format   All securable objects arrange their access rights by using the access mask format as shown in the following Figure.     Figure 3

In this format, the low-order 16 bits are for object-specific access rights, the next 8 bits are for standard access rights, which apply to most types of objects, and the 4 high-order bits are used to specify generic access rights that each object type can map to a set of standard and object-specific rights.  TheACCESS_SYSTEM_SECURITY bit corresponds to the right to access the object's SACL.  The bits in this value are allocated as follows.

 

 

Standard rights bits, 16 to 23, contain the object's standard access rights and can be a combination of the following predefined flags.

 

 

The following constants represent the specific and standard access rights that can be used as#define preprocessor directives:

#define SPECIFIC_RIGHTS_ALL                       0x0000FFFF

#define STANDARD_RIGHTS_REQUIRED      0x000F0000

#define STANDARD_RIGHTS_ALL                   0x001F0000

All Windows securable objects use an access mask format that includes bits for the following types of access rights:

• Generic access rights.

• Standard access rights.

• SACL access right.

• Directory services access rights.

Generic Access Rights

 

Securable objects use an access mask format in which the four high-order bits specify generic access rights. Each type of securable object maps these bits to a set of its standard and object-specific access rights. For example, a Windows file object maps theGENERIC_READ bit to theREAD_CONTROL andSYNCHRONIZE standard access rights and to the FILE_READ_DATA,FILE_READ_EA, andFILE_READ_ATTRIBUTES object-specific access rights. Other types of objects map theGENERIC_READ bit to whatever set of access rights is appropriate for that type of object. You can use generic access rights to specify the type of access you need when you are opening a handle to an object. This is typically simpler than specifying all the corresponding standard and specific rights. The following table shows the constants defined for the generic access rights.  Applications that define private securable objects can also use the generic access rights.

 

 

Standard Access Rights

 

Each type of securable object has a set of access rights that correspond to operations specific to that type of object.  In addition to these object-specific access rights, there is a set of standard access rights that correspond to operations common to most types of securable objects.  The access mask format includes a set of bits for the standard access rights.  The following table shows the Windows constants defined for the standard access rights.

 

 

The Windows API also defines the following combinations of the standard access rights constants.

 

 

SACL Access Right

 

The ACCESS_SYSTEM_SECURITY access right controls the ability to get or set the SACL in an object's security descriptor.  The system grants this access right only if theSE_SECURITY_NAME privilege is enabled in the access token of the requesting thread.  A SACL contains ACEs that specify the types of access attempts that generate audit reports.  Each ACE identifies a trustee, a set of access rights, and a set of flags that indicate whether the system generates audit messages for failed access attempts, successful access attempts, or both.  SACL will be discussed in detail under Audit topic later on.

 

Directory Services Access Rights

 

Each Active Directory object has a security descriptor assigned to it.  A set of trustee rights specific to directory service objects can be set within these security descriptors.  These rights are listed in the following table.

 

 

When a thread tries to open a handle to an object, the thread typically specifies an access mask to request a set of access rights.  For example, an application that needs to set and query the values of a registry key can open the key by using an access mask to request theKEY_SET_VALUE andKEY_QUERY_VALUE access rights.

 

How Security Descriptors are Set on New Directory Objects

 

When you create a new object in the Active Directory, you can explicitly create a security descriptor and then set that security descriptor as the object's nTSecurityDescriptor property.  Active Directory uses the following rules to set the DACL in the new object's security descriptor:

1. If you explicitly specify a security descriptor when you create the object, the system merges any inheritable ACEs from the parent object into the specified DACL unless the SE_DACL_PROTECTED bit is set in the security descriptor's control bits.

2. If you do not specify a security descriptor, the system builds the object's DACL by merging any inheritable ACEs from the parent object into the default DACL from the classSchema object for the object's class.

3. If the schema does not have a default DACL, the object's DACL is the default DACL from the primary or impersonation token of the creator.

4. If there is no specified, inherited, or default DACL, the system creates the object with no DACL, which allows everyone full access to the object.

 

The system uses a similar algorithm to build a SACL for a directory service object.  The owner and primary group in the new object's security descriptor are set to the values you specify in thenTSecurityDescriptor property when you create the object.  If you do not set these values, Active Directory uses the rules, listed in the following table, to set them.

 

 

Default Security Descriptor

 

With Active Directory you can also specify default security for each type of object.  This is specified in thedefaultSecurityDescriptor attribute in theclassSchema object definition in the Active Directory schema.  This security descriptor is used to provide default protection on the object if there is no security descriptor specified during the creation of the object.  Take note that ACEs from a default security descriptor are handled as if they were specified as part of object creation.  Therefore, the default ACEs are placed preceding inherited ACEs and override them as appropriate.  ThedefaultSecurityDescriptor is specified in a special string format using the Security Descriptor Definition Language (SDDL).  Two functions can be used to convert binary form of the security descriptor to string format and vice versa.  These functions are:

1. ConvertSecurityDescriptorToStringSecurityDescriptor().

2. ConvertStringSecurityDescriptorToSecurityDescriptor().

 

 

 

 

 

Further reading and digging:

 

1. For Multi-bytes, Unicode characters and Localization please refer to Locale, wide characters & Unicode (Story) and Windows users & groups programming tutorials (Implementation).

2. Structure, enum, union and typedef story can be found at C/C++ struct, enum, union & typedef.

3. Linux Access Control Lists (ACL) info can be found atAccess Control Lists.

4. Check the best selling C, C++ and Windows books at Amazon.com.

5. Microsoft C references, online MSDN.

6. Microsoft Visual C++, online MSDN.

7. ReactOS - Windows binary compatible OS - C/C++ source code repository, Doxygen.

8. Notation used in MSDN is Hungarian Notation instead of CamelCase and is discussedWindows programming notations.

9. Windows data type information is inWindows data types used in Win32 programming.

 

 

|< Windows Access Control Programming 1 | Main | Windows Access Control Programming 3 >|Site Index |Download |

---