Windows Integrity Checks (Mandatory Access Control)

Integrity checks, Windows Integrity Mechanism or the Windows Integrity Control (WIC) is the implementation of MAC (Mandatory Access Checks) in Windows. According to definition in the "Orange Book", Mandatory Access Control is defined as "a means of restricting access to objects based on the sensitivity of the information contained in the objects and the formal authorization (i.e., clearance) of subjects to access information of such sensitivity".

So from the above we understand that there are two parts of the MAC or the Windows Integrity Mechanism that need to be discussed and understood. The means of restricting access to objects as represented by a 'label' by subjects as represented by a 'token'.

This article is an endeavor to explain the Why, What and How of Windows Integrity Mechanism as used by labels (objects) and tokens (subjects).

Note: When discussing Windows Integrity Mechanism all objects cannot be considered securable objects. Files on a Windows FAT32 partition are also objects but they cannot be considered securable as they do not have security descriptor. There are many types of securable objects in Windows: Files and Folders Processes and Threads Services Registry Keys Ports AD objects DCOM Objects Kernel internal objects like mutexes, semaphores and events. Named pipes Access tokens Network Shares Job Objects Printers

WIC is a core component of Windows Security Architecture from Windows Vista and onwards.

Why (Purpose of) Windows Integrity Control

MS Windows is a message oriented environment. In Windows different applications running under the same user can communicate with each other by sending and receiving messages from/to each other. One method of an application running under a user and reading messaging generated by another application, running under the same user, is installing system Hooks. The Hook lets an application read messages before they are delivered to their final destination.

This gives rise to the possibility that an untrusted application, possibly malware, can install a hook and receive messages of a trusted application that may be sending out sensitive information.

The security subsystem assigns integrity levels to different processes depending on their level of trust. With WIC in place this is not possible for a process of low integrity to communicate with a process of higher integrity.

Before WIC users could manipulate their own data, and also damage the system, but after WIC a normal user (with medium integrity) cannot, intentionally or unintentionally, damage the system.

According to Microsoft (microsoft.com) the goals that were kept in mind when designing the WIC were the following:
a-  Integrity of Subjects: That integrity levels must be assigned to every security token, automatically, during token creation.
b-  Mandatory labels for subjects: Mandatory labels will be assigned by the security subsystem, automatically. 
c- Simplicity: Mandatory Access Control by nature, is a very simple security framework. It was a design goal to keep as few integrity level as possible, to keep the basic architecture simple to understand and use. 
d- Flexibility: Integrity policy must be flexible to meet the access requirements of different object resource managers, and to allow for future extensibility. 
e- Support of legacy systems: Integrity mechanism must integrate with existing security architecture to minimize impact to the large legacy of system and application code that depends on Windows security. 
f- Automatic integrity level configuration: The user and/or administrators do not need to configure integrity levels for the enforcement mechanism to work correctly. The security subsystem automates this security configuration.

Rules of access

It is advisable that the reader not try to associate WIC with classical access control frameworks as Bell-Lapadula, Biba Phipps or Clark-Wilson. WIC deviates from all classical frameworks in one way or the other.

The integrity labels are stored in the System Access Control List (SACL) of an object. During access check the DACL is compared first followed by the SACL. During the DACL check the permissions are compared with the SIDs of the subject, followed by the SACL check to see if the access should generate any auditing event. Also the Integrity level of the object is checked against the integrity level of the subject. If a write access is allowed according to the DACL but the integrity of the accessing subject is lower than the object's integrity level, the access will be denied.

Information disclosure is prevented only with respect to process address space. Information sharing is common in the Windows environment and is an essential part of the user experience, an example of this is copy and paste. The user can copy from an application of a high integrity level and paste to an application with low integrity. (See UIPI).
Two processes running under the same user with two different tokens (filtered and elevated) will not be able to share a resource, unlike two threads of the same process. Therefore it is not recommended that threads of the same process have the different integrity levels as there is no boundary in the address spaces within a process. If it is really required that two threads operate for a common purpose, it is best to launch two separate processes programmed to collaborate with one another.

Access Tokens and Labels

The three key elements that make the WIC work are the following:
1- The Security Subsystem (Security Reference Monitor)
2- Mandatory Labels
3- Access Tokens

In the above list integrity levels have not been included as they are used by all three. In one sentence: “Integrity Level of an access token is compared to integrity level of Mandatory Label in order to decide whether the subject can get access to the object or not".

Labels

Refer to the article (http://securityinternals.blogspot.ae/2013/12/security-identifiers-in-microsoft.html), where we discussed that role of subject and regarding the object; that Subjects are the active entities which need to access (read, write or execute) resources example file, folders, other processes.

The integrity level is now included as an ACE in the security descriptor. In the security descriptor there is a new section called the Security Access Control List and it contains the mandatory label.

The label is 32 bit number, with different values with a difference of 0x1000 (hex). Popularly only 6 numbers are used for the following values (taken from winnt.h):

Integrity number (in Hex)	Name of integrity level	Integrity Level SID	Symbol
0x0000	Untrusted	S-1-16-0	SECURITY_MANDATORY_UNTRUSTED_RID
0x1000	Low	S-1-16-4096	SECURITY_MANDATORY_LOW_RID
0x2000	Medium	S-1-16-8192	SECURITY_MANDATORY_MEDIUM_RID
0x3000	High	S-1-16-12288	SECURITY_MANDATORY_HIGH_RID
0x4000	System	S-1-16-16384	SECURITY_MANDATORY_SYSTEM_RID
0x5000	Protected Process (Installer)	S-1-15-20480	SECURITY_MANDATORY_PROTECTED_PROCESS_RID

When comparing integrity values the corresponding numbers are compared to see which subject's access is equal/greater than or less than an object's mandatory label.

In version of Windows before Vista, the security descriptor has a portion called a Discretionary Access Control List which is where the information regarding access by specific users and specific actions (read, write, execute) was mentioned.

With Mandatory Access Control there is now a new section called the System Access Control List as shown in the figure below (taken from msdn.microsoft.com):

Security Descriptor for objects in Windows Vista and Later

The SACL contains the mandatory label, which should contain the integrity level for the object. Every single type of object (file, process object, resource object, thread object, access token object) has an associate security descriptor and therefore an integrity level.

Explicit Labels are assigned to:

·         Processes

·         Thread

·         Access Token

·         Job

At creation time, other objects like files on a Vista (and later) NTFS file system can be set either implicitly or it can be inherited by a file from its parent container.

For files when the file is created, i.e. after creating a text file in notepad, as soon as the file is saved to the disk it will be assigned an implicit integrity level of Medium or it will inherit from its parent folder if the parent folders inheritance is turned on.

Since the access tokens also have security descriptors which have a mandatory label containing an Integrity level, this can cause a reader to be confused between the integrity level in the security descriptor and the integrity level assigned to the access token?

The answer is in the diagram below of the structure of an access token (taken from msdn.microsoft.com):

Access Token's Data Structure

The IntegrityLevelSID contains the Sid of the integrity level assigned to the access token, whereas the security descriptor, is the property of an access token since it is an object. The object needs to have an ACL for access control. The DefaultDACL contains the ACL which would contain the integrity of the access token as an object.

The integrity label can be changed by a user who has permission to change the information in an object's SACL, this can be done by the administrator and owner of the object using tools like chml, cacls or icacls.

Tokens

Access tokens are initialized at interactive logon or when network authentication occurs. During initialization the primary access token contains security related information like the SID of the user, SID’s of all the groups the user is a member of and a list of all his privileges. The access token details can be viewed by typing the following in a prompt:

C:/> whoami /all /fo list

The command will give a list of all group memberships, privileges and the integrity level of the access token. The integrity level assigned to the access token is also called the subject integrity level.

Choosing an integrity level for an access token

The decision to grant a particular integrity level is made at the initialization moment. The exact integrity level is determined based on the presence of specific groups in the TOKEN_GROUPS structure. The structure of the TOKEN_GROUPS can be found in the winnt.h file.

The following table (from technet.microsoft.com) shows the names of the groups which, if present, are used to provide the access token an integrity level.

Group	SID	Assigned Integrity Level
Local System	S-1-5-18	System
Local Service	S-1-5-19	System
Network Service	S-1-5-20	System
Administrators	S-1-5-21domain-500	High
Backup Operators	S-1-5-32-551	High
Network Configuration Operators	S-1-5-32-556	High
Cryptographic Operators	S-1-5-32-569	High
Authenticated Users	S-1-5-11	Medium
Everyone(World)	S-1-1-0	Low
Anonymous	S-1-5-7	Untrusted

Note that the access token for a standard user is assigned a medium integrity.

Inheritance of the access token

When a user logs into windows, interactively, the explorer.exe process is started and is passed the

The exact integrity level of the process depends on the integrity level of the executable file. If the access token in medium and the executable file’s integrity is High the resulting process will be high. For example a user with an access token of Medium runs regedit.exe. Regedit.exe has a high priority which it inherits from the parent C:/Windows folder. When the user issues the command regedit.exe he is prompted by the User Access Control prompt to allow the use of an elevated token. Normally a standard user works in a default access token which is called the filtered token. The filtered token has a medium integrity level and it can access, use, abuse everything in it’s ownership; the right to access, use or abuse anything that is system wide is called a privilege. The elevated token has a lot of privileges which can be seen by invoking the command prompt (cmd.exe), via ‘Run as Administrator’ and then running the command:

C:/> whoami /all /fo list

The resulting list of privileges can be compared with that of a standard user. Although the group membership be different in a couple of cases, the elevated token has a very large number of privileges.

The elevated token is another version of the same user on the machine but with Administrator rights. Whenever a program/application is launched by a standard user to ‘Run as administrator’ he is basically invoking his elevated token. Windows is the only operating system that provides two versions of the same user.

We look at the resulting regedit.exe process which, as expected, runs with a High level integrity as shown below:

Right click and view image to view a larger image.

Processes in different modes

Processes can be programmed to run at a low level integrity. If a user runs an application, the application will first launch with the user’s access token, this process behaves as a broker between the system and the low integrity application. The broker application then initiates a child process of lower integrity. Examples of applications that are built run in low integrity level are Internet Explorer in ‘Protected Mode’ and ‘Google Chrome’. Every Windows store App is going to run at low integrity.

When a low integrity level process is running it cannot write to disk and therefore won’t be able to save anything. Therefore the parent process of such applications behave as brokers, they implement the rules and provide the service like file system access with the access rights of the person who launched the service.

About the Author: Saquib Farooq Malik, is a senior Information Security Consultant in Dubai. Saquib Specializes in Vulnerability Assessment, Penetration Testing and Microsoft Windows Security, implementations of ISO 27001 in different corporate environments in the Middle East.

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