Last February when I wrote the Windows Security Survival Guide on the TechNet Wiki my goal was to create a document where we emphasize Windows features and functionalities that supports the security pillars of Confidentiality, Integrity and Availability. The goal of this series of blog posts that I’m going to write here is to explore some areas of the Windows Security Survival Guide where Windows platform can contribute with the three core security pillars, this week I will start with Integrity. Windows Integrity Mechanism
There are a variety of resources available when the subject is WIM (Windows Integrity Mechanism), but before even go to this direction, what about understand what we want to achieve with Integrity on the OS perspective? We all know why we want to keep integrity while data is in transit, but what about when data is still in process in the OS? We can use the following definition of integrity that fits perfectly in this discussion:
“The integrity level is a representation of the trustworthiness of running application processes and objects, such as files created by the application. The integrity mechanism provides the ability for resource managers, such as the file system, to use pre-defined policies that block processes of lower integrity, or lower trustworthiness, from reading or modifying objects of higher integrity. The integrity mechanism allows the Windows security model to enforce new access control restrictions that cannot be defined by granting user or group permissions in access control lists (ACLs).” Source http://msdn.microsoft.com/en-us/library/bb625957.aspx
Enforcing some level of control is the core goal of many security models, such as Clark-Wilson and Biba Model. Biba integrity model for example is based on the idea that a subject with a specific level of integrity cannot write in a higher level and cannot read on the lower level. The goal here is not to read data from a lower level to avoid data contamination (reading from a source that has a lower level) and also the integrity of higher levels by disallowing lower level to write to it.
The same WIM article mentioned before brings a great paragraph that explains what Windows integrity model does not implement from Biba model:
“The Windows integrity policies do not inhibit or prevent higher-integrity subjects from reading or executing lower-integrity objects. There are many examples of attacks where reading malformed, untrusted input data results in an exploit of a vulnerability in an application and arbitrary code execution. The Windows integrity mechanism does not inhibit or prevent reading data at any level. Windows does not enforce a strict integrity policy described in the Biba model. The integrity design assumes that processes that are designed to handle untrusted data from an unknown or untrusted source are running at a lower integrity level, or that untrusted data is verified before use. However, the Windows integrity mechanism does not enforce that constraint.”
But WIM resembles the Biba model in other areas, such as:
There are many Windows features that enforces access level control, not only from the administrative standpoint, but also from the developer standpoint. For example the SYSTEM_MANDATORY_LABEL_ACE Structure allows you to implement mandatory access policies. Another function that leverages the concept of integrity level is SidDominates, which compares the mandatory integrity levels expressed in two SIDs.
This quick overview of integrity in Windows is just a reminder that there are many areas to explore when the subject is integrity other than only be concern about integrity when data is in transit. Make sure to review the Integrity section of the Windows Security Survival Guide for more information and links to Windows feature that deals with Integrity.