Access Control Structures in Windows

As discussed in a previous article regarding Windows Integrity Control (http://securityinternals.blogspot.ae/2014/01/windows-integrity-checks-mandatory.html) all objects in a Windows environment may not be securable objects, e.g. FAT 32 filesystems, CDFS filesystems. There are many types of securable objects in Windows:

1. Files and Folder
2.  Processes and Threads
3. Services
4. Registry Key
5. Ports
6. AD objects
7. DCOM Objects
8. Kernel internal objects like mutexes, semaphores and events.
9. Named pipes
10. Access tokens
11. Network Shares
12. Job Objects
13. Printers

Security Descriptor Data Structure

Every securable object has a security descriptor. A security descriptor is a data structure that contains all the security related information regarding a securable object. The security descriptor construct has been designed to carry the following information:

·         Who owns the object?

·         What is the object’s primary group?

·         Discretionary Access Control Information

·         Which Users and Groups should be audited?

·         Mandatory Access Control Information (Mandatory  Label: Integrity Level)

The data structure of a security descriptor according to winnt.h is shown below:

                                   Fig 1: Structure of a Security Descriptor Clieck Image to enlarge

Row 1: The first row contains three parts:

• Revision: Currently this is 1.
• Reserved: Reserved bits, not used yet.
• Control: Contains a number of flags that describe the nature of the security descriptor. Details for the individual flags can be found at:

http://technet.microsoft.com/en-us/library/cc962005.aspx

Row 2: Pointer to Owner contains a pointer to the SID of the owner of the object the security descriptor belongs to. The row contains a pointer and not an SID because the SID, by its nature, is of varying length.

Row 3: Pointer to Group contains a pointer to the SID of the primary group of the object to which the security descriptor belongs to. This is not a requirement of the Windows environment but it is there for the sake of compatibility with POSIX.
In POSIX compliant systems an object’s permissions are set among OGA (Owner, Group, All/Everyone).  When a user is User1 created it also creates the User1 group. If an object belongs to only one user User1, it automatically belongs to that users’s group the User1 group. Being a part of a group is inevitable in a POSIX environment. Therefore, the security descriptor holds a pointer to the SID of the primary group of the object.

Row 4:Pointer to SACL points to the Security Access Control List (Discussed below)

Row 5: Pointer to DACL point to the Discretionary Access Control List (Discussed below)

Access Control Lists

The last two pointers in the security descriptor contain pointers to the main payload of a security descriptor.  The structure of an Access Control List is a very simple one as per winnt.h shown below:

Fig 2: Data Structure of an Access Control List and an Access Control Entry

The access control list contains the Access Mask, the Access Mask contains the actual mention of the permission on the object. The information regarding the subject are contain in ACE, exactly what permissions are granted to the subject? That is dictated by the Access mask.

As per winnt.h the access mask is a DWORD (a double word) i.e. a 32 bit structure which has different bits set to 1 or 0 for granting or denying a particular permissions. If a permission is set to 1, then in case of a DACL that access would be allowed and if the same ACE is inside an SACL then the access will generate an audit event. The structure is shown below:

Fig 3: Structure of an Access Mask

The main purpose to have a security descriptor is to house access control information and access control lists to be exact. There are three types of access control lists:

a.       Discretionary Access Control Lists

b.      Security Access Control Lists

c.       Mandatory Access Control Lists

Discretionary Access Control Lists

Discretionary Access Control Lists or DACL are, as their name implies, access control lists at the discretion of someone. This someone is the creator or the owner of the object. The DACL can be altered usually by the administrator and always by the owner (and creator, if they are the same person) of the object.
Since DACL is the type of access control list that can be altered by users, this is the type of ACL referred to the most when talking about access control lists.

Note: It is possible for a DACL to have no values, an empty DACL would mean that no one has access to the object. This can be changed by the owner of the object. An error may result in an object not having a DACL or having a NULL DACL. A Null DACL is different from an empty DACL. In the latter the access is defined but no one has been granted access. In the latter access control has not been defined therefore anyone can access the object.

System Access Control Lists

The security access control (SACL) list identical in structure to the discretionary access control list. The difference is that the system access control lists control which access attempts get audited. Let’s take the example of an ACL that grants read permission to a subject on an object. If the ACL is a DACL then the read access is granted, but if the ACL is a SACL then the read access to the object by that particular subject will generate an audit event.
The SACL is used to control the following audit properties:

• Which subjects should be audited when accessing the object
• Which access events should be audited for these subjects
• Whether a Success or Failure event is generated for an access event, depending on the permissions granted in the DACL for the object.

The success or failure will depend on the access permission set in DACL. In order to grant read access to a subject on an object and generate audit events when the access takes place, there will be two similar ACE’s in the ACL with only one difference, that one will be an DACL and the other will be an SACL.

Mandatory Access Control List

The mandatory access control list (MACL) is different in behavior from its other two siblings. Firstly the mandatory access control list is managed by the security subsystem rather than the user. The mandatory is assigned by the system based on the sensitivity of that object. The mandatory access implements Windows Integrity Control explained in detail here: 
http://securityinternals.blogspot.ae/2014/01/windows-integrity-checks-mandatory.html

The mandatory access control is implemented in an extra ACE in the SACL of the object.

Access Mask

The high end four bits of the access mask contain the basic access permissions of read (GR=Generic Read), write (GW=Generic Write), execute (GX=Generic Execute) and All i.e. read, write and execute (GA=Generic All).  These generic access permissions are there for all objects, whether a file system object (directory or file), a registry key or a process object. In case of a file system object a GR would be referred to as an FR (FILE_GENERIC_READ) and in case of a GR on a registry key the GR would be called a KR (KEY_GENERIC_READ), what is important here is to know that these names only tell us which bits are on or off representing access allowed or denied respectively.

Standard Rights in Figure 3, are the standard rights on the object’s meta data. The standard rights include:

·         DELETE: The ability to delete the object i.e. alter it’s entry in the filesystem or registry etc.

·         READ_CONTROL: Ability to read an object’s security descriptor

·         WRITE_DAC: Ability to write to its DACL

·         WRITE_OWNER: Ability to change ownership of the object.

·         SYNCHRONIZE: Ability to monitor the state of the object for changes.

The low end 16 bits have object specific rights, this means for file systems objects (applicable for files and folders) the rights would be to read, traverse a folder, execute a file, write to a file, create a sub-directory in a folder etc. These rights would be different for registry keys and, again, different for other objects.
For a list of a file system specific rights go to : http://msdn.microsoft.com/en-us/library/windows/desktop/aa446614%28v=vs.85%29.aspx

Relationship of the Access Control Data Structures

The hip bone connected to the thigh bone.

1. All Objects have a Security Descriptor
2.  A Security Descriptor contains ACLs Fig-1
3. ACLs contain ACEs Fig-2
4. ACE contain Access Masks Fig-3. The access masks are the leaf nodes where the permissions are actually written. The structure mentioned above are all containers that organize the security meta-data of objects.

About the Author: Saquib Farooq Malik, is a senior Information Security Consultant at ITButler e-Services(www.itbutler.com.au) . Saquib Specializes in Vulnerability Assessment and Penetration Testing, implementations of ISO 27001 in different corporate environments in the Middle East.

He is a CISSP, an ITILv3 Foundation certified professional, ISO 27001 Lead Auditor, Tenable Certified Nessus Auditor and a Lumension Certified Engineer.