Steve Riley on Security

Formerly of Microsoft's Trustworthy Computing Group.


Mandatory integrity control in Windows Vista

  • Comments 27
  • Likes

One of my favorite new security features in Windows Vista is Mandatory Integrity Control (MIC). It’s a classical computer science concept from the 1970s that’s finally getting its first commercial implementation—and of this I’m quite proud.

While discretionary access control lists (DACLs) are useful, they have some limitations. They do little to safeguard system stability and they can’t stop malicious software from tricking users into executing it. MIC adds the notion of trustworthiness evaluation into the operating system. Subjects with low degrees of trustworthiness can’t change data of higher degrees; subjects with high degrees of trustworthiness can’t be forced to rely on data of lower degrees. MIC implements an information flow policy and provides the enforcement mechanism.

When a user logs on, Windows Vista assigns an integrity SID to the user’s access token. The SID includes an integrity label that determines the level of access the token—and therefore the user—can achieve. (The SID’s format is S-1-16-<label>, where <label> is a number that represents the integrity level.) Securable objects (files, folders, pipes, processes, threads, window stations, registry keys, services, printers, shares, interprocess objects, jobs, and directory objects) also receive an integrity SID, which is stored in the system access control list (SACL) of the object’s security descriptor. The label in the SID specifies the integrity level of the object.

During an access check, before checking the user’s access through the DACL, Windows Vista checks the integrity level of the user and compares it to the integrity level of the requested object. If the user’s level dominates (that is, is equal to or greater than) the object’s level, the user will be allowed to write to or delete the object, subject of course to the DACL. If the user’s level doesn’t dominate the object’s, then the user can’t write to or delete the object regardless of what the DACL says. Integrity control, therefore, trumps access lists.

Windows Vista defines four integrity levels: low, medium, high, and system. Standard users receive medium, elevated users receive high. Processes you start and objects you create receive your integrity level (medium or high) or low if the executable file’s level is low; system services receive system integrity. Objects that lack an integrity label are treated as medium by the operating system—this prevents low integrity code from modifying unlabeled objects.

For those keeping track… Yes, there’ve been some changes since I spoke about MIC at TechEd. First, the label numbers have changed from 100/200/300/400 to 4096/8192/12288/16384, which in hex are 1000/2000/3000/4000. So don’t use the numbers when referring to labels, because they might change again! Second, processes no longer receive the lower of your integrity or the file’s integrity—instead, process integrity behaves as I described above. Third, we no longer use MIC to enforce Windows resource protection (WRP). All operating system files are now unlabeled, meaning they default to medium integrity. The files are ACLed such that only the trusted installer has write access; everyone else, including administrators, has only read and execute access.

Consider a scenario. Say you receive an attachment in email. When you save it, it’s written with low integrity because it came from the Internet—an untrusted source. When you execute the attachment, its process runs at low integrity because the file object is labeled low; therefore, your data (labeled medium or high) is protected from malicious writes by the attachment. It will, however be able to read your data. MIC implements a form of the Biba model, which ensures integrity by controlling writes and deletions. Contrast this with the more well-known Bell-LaPadula model, which describes levels of confidentiality by controlling reads.

Internet Explorer Protected Mode (IEPM) is built around mandatory integrity control. The IEPM process and extensions run at low integrity and therefore have write access only to the Temporary Internet Files\Low folder, History, Cookies, Favorites, and the HKEY_CURRENT_USER\Software\LowRegistry key. MIC prevents IEPM from writing anywhere else in the file system or registry—so no more silent installs of keystroke loggers into your Startup folder. And because the desktop runs at medium integrity, IEPM can’t send messages to it—thwarting shatter-style attacks. Because these new restrictions might break some applications, a compatibility mode virtualizes access to medium integrity resources (like the Documents folder and the HKEY_CURRENT_USER hive) by redirecting writes to low integrity locations (Documents and Settings\%userprofile%\LocalSettings\TemporaryInternet Files\Virtualized and HKEY_CURRENT_USER\Software\Microsoft\InternetExplorer\InternetRegistry).

While it’s completely invisible, mandatory integrity control is an important advance in maintaining the security and stability of Windows Vista. I hope you’ll come to appreciate it as much as I do.

  • I guess we have different interpretations of the function of a model. To me, a model is a guideline, something to base a design on, not to constrain. Biba and Bell-LaPadula describe idealized functionality -- functionality which can be fully implemented if necessary, as you mention. But in the more common cases of integrity and access control, certain elements of the models must be relaxed in order for the controls to be broadly useful.

    It's a good question about the OS files being unlabeled. Essentially, you've got two choices for protecting the files: label them system integrity (higher than admins) or ACL them read-only for everyone except the trusted installer. Neither approach will stop malicious admins or malware running as admin: in the former, the admin or malware can directly modify the master file table and remove the integrity labels on the files; in the latter, the admin or malware can take ownership of the files and change the ACLs. This reinforces the point that administrators must be people you trust.

    There's one advantage to the approach we finally took. Setting the ACL to trusted-installer:full-control, everyone-else:read-execute-only makes very obvious the intention of the security policy. A system integrity level wouldn't be so clear. Generally, it's best to think of integrity checks as a compliment to access control, not a replacement.

  • Steve, in your last paragraph you are (again) mixing up access controls with integrity controls.

    The whole point behind mandatory controls is exactly that, they are mandatory. File ownership, access  and integrity are no longer at the discretion of the system administrator, they are enforced by the policy inspection mechanism according to the label they carry. And that means *everything* on the system has to have a label. It also means that an administrator might not be able to touch stuff on the system. In that case you no longer need to rely on trust in the administrator. This is a *fundamentally different* way of thinking about both access and integrity.

    And that is the issue here. You are not *enforcing* mandatory integrity. You are not enforcing anything. You are providing an extra integrity checking mechanism. The fact that it is provided is a good thing. The fact that it is labeled by your marketing department as "mandatory integrity controls", which it is clearly *not*, is confusing at best. There is no such thing as mandatory integrity on Vista if I as administrator can still alter the master file table.

  • Rob, I'm not sure we'll come to agreement here. I disagree with your assertion that I am "mixing up" access controls with integrity controls. I certainly understand the differences, the definitions of idealized implementations, and the reality of applying the computer science principles they embody to the real-world implementations that derive from them.

    Integrity controls in Windows Vista *are*, in fact, mandatory. Any object that has a security descriptor is evaluated against integrity controls, even if the object itself is unlabeled. In the case of unlabeled objects, the operating system assumes a label of medium.

    One of the fundamental laws of computer security states that if a bad guy can get software to run on your computer, then it isn't your computer anymore. In my description of how an administrator might alter labels, I'm simply being honest about how locally-executed malicious code can cause damage. Every computer system in the world, regardless of operating system, can be owned by a sufficiently-motivated attacker.

  • Hi --

    I noted that several of you wanted a tool that would let you examine and change integrity levels on objects in Vista.  icacls does it, but it's still broken and a bit limited, so I wrote a tool that may be useful.  It's at and it's a command-line tool that lets you see an object's IL, change it via either SDDL (ugly but flexible) or with some simpler options.  I hope this helps someone!
    -- Mark

  • I have finally got my outlook unread messages down to zero. There are 1229 Messages in my deleted Items...

  • In prior Vista betas, Process Explorer used to show a SID flag named "DesktopIntegrity" in the SAT of a process.  The "Integrity" flag is still around, but what happened to "DesktopIntegrity"?

    I assume that "DesktopIntegrity" was for User Interface Privilege Isolation (UIPI), so does this mean MIC is no longer being used for UIPI just like Windows Resource Protection no longer uses MIC?

    Any other MIC changes in build 5728 to know about?

    Thanks again for the blog, it's hard to find this information!

  • Two weeks ago I delivered my Windows Vista System Integrity presentation at the TechEds in New Zealand

  • Steve,

    at first thanks for your blog and the valuable insight it provides. After reading your post on MIC I decided to have a look on it, given I've done some research on multi level security systems lately. I stumbled across some obscurities though which I'd like to clarify here. Please note that this was my first installation of Win Vista ever so maybe there are some misunderstandings of concepts on my side...

    So this is what I did in detail:

    - default installation of RC1 (build 5600)

    - creation of first and single user (here 'erey')

    - logged in as erey, with restricted token and the following privs



    Privilege Name                Description                          State  

    ============================= ==================================== ========

    SeShutdownPrivilege           Shut down the system                 Enabled

    SeChangeNotifyPrivilege       Bypass traverse checking             Enabled

    SeUndockPrivilege             Remove computer from docking station Disabled

    SeIncreaseWorkingSetPrivilege Increase a process working set       Disabled

    SeTimeZonePrivilege           Change the time zone                 Disabled

    - creation of c:\tools directory and download of tools to it (Sysinternals: accesschk, ProcessExplorer and Mark Minasi's chml)

    === Integrity level of files

    I then checked the integrity levels of the files just downloaded and here comes the first surprise (or just personal misunderstanding):

    AccessChk v2.0 - Check account access of files, registry keys or services

    Copyright (C) 2006 Mark Russinovich

    Sysinternals -


     Medium Mandatory Level (Default)

     RW BUILTIN\Administrators


     R  BUILTIN\Users

     RW NT AUTHORITY\Authenticated Users


     Medium Mandatory Level (Default)

     RW BUILTIN\Administrators


     R  BUILTIN\Users

     RW NT AUTHORITY\Authenticated Users

    I had naively expected that these files had an integrity level of 'low' given their origin (internet) and the process that wrote them to disk (IE, supposedly running with 'low' integrity).

    Question: why do these files have an integrity level of 'medium'? Lack of intlevel assigning capability in IE in current state?

    Or the other way round: what the hell will ever get intlevel 'low' if not such files (executables downloaded from the internet, restricted user, by means of IE, from untrusted sources)?

    [one could argue that the Sysinternal stuff is signed, but at least the Minasi stuff isn't].

    === Integrity level of processes

    Looking at the integrity level of processes I noticed the following:

    1) Restricted token user 'erey' invokes procexp.exe (medium) => process integrity: medium

    2) (Run as) Administrator 'erey' invokes procexp.exe (medium) => process integrity: high

    This is consistent to your description (or at least my understanding of it ;-):

    "when a user invokes a file whose integrity level is higher than low the resulting process will run with the integrity level of the user"

    [which contrasts to the Biba model where the lower level of subject (user) and object (file) is chosen, but as you correcty say a model is just a basis...].

    This again rises the question: if a user runs an internet-downloaded executable with admin privileges (and this will happen rather often, think of all the little helper tools available from the internet, requiring admin privs for whatever reason), the resulting process will run with intlevel 'high'. Where's the protection benefit then?

    I understand the behaviour is consistent (however I'm not sure if or why the variation from Biba is a good idea here) and I understand that maybe the process needs a 'high' intlevel (to perform it's functions correctly) - and yes UAC came into place and asked me when invoking procexp as an admin - but I'm a bit sceptic about the use then. My previous understanding of "in Vista we're running IE with low privs to protect you from all that bad stuff coming from the internet" was a bit different...

    === Modifying intlevel of files and the results

    Time for a change of the integrity level of an executable now...

    Trying that gave the following:

    - created a copy of procexp.exe

    1) - tried (as 'erey' with restricted token) to modify intlevel by

    C:\tools>chml procexp_mod.exe -i:l

    => did not work ("Access is denied").

    2) I then gave the user 'erey' the privilege "Modify an object label" by gpedit (+ gpupdate).

    After logging out and in again I noticed I did not even (seem to) have it when running cmd.exe as admin:



    Privilege Name                  Description                               State  

    =============================== ========================================= ========


    SeCreateGlobalPrivilege         Create global objects                     Enabled

    SeRelabelPrivilege              Modify an object label                    Disabled

    SeIncreaseWorkingSetPrivilege   Increase a process working set            Disabled

    But now chml worked:

    C:\tools>chml procexp_mod.exe -i:l

    chml v1.010 -- Change Windows Integrity Level

    by Mark Minasi (c) 2006

    "chml -?" for syntax, examples and notes.

    Integrity level of procexp_mod.exe successfully set to low.


    C:\tools>accesschk.exe -i procexp_mod.exe

    AccessChk v2.0 - Check account access of files, registry keys or services

    Copyright (C) 2006 Mark Russinovich

    Sysinternals -


     Low Mandatory Level (!!!)

     RW BUILTIN\Administrators


     R  BUILTIN\Users

     RW NT AUTHORITY\Authenticated Users

    3) Invoking the procexp_mod.exe with intlevel 'low' gave the following:

    invoking as restricted user 'erey' => process integrity: 'low' (as indicated by ProcessExplorer)

    invoking as admin => process integrity 'high'

    BIG surprise! what's going on here? High integrity user runs low integrity executable and resulting process runs on 'high' integrity!?!


    a) Looking at the "Explain" text in gpedit:

    "Modify an object label

    This privilege determines which user accounts can modify the integrity label of objects, such as files, registry keys, or processes owned by other users. Processes running under a user account can modify the label of an object owned by that user to a lower level without this privilege."

    ... I do not understand why 1) didn't work. I invoked a process cmd.exe (supposedly running with intlevel 'medium' given the user was restricted) and tried to modify a file I owned. The observed behaviour seems to contrast the 'help text' but seems consistent to Mark Minasi's comments in the manpage of chml.

    b) why did user 'erey' seemingly not dispose of SeRelabelPrivilege after assigning it to him directly and logging out+in, neither as restricted user nor as admin? or at least: why did 'whoami' indicate that? Problem of privilege enumeration in 'whoami'?

    c) please explain scenario 3 mentioned above! ;-))

    This seems to contradict fully your explanation (or I got it totally wrong).

    There seems to be a different behaviour as for the process intlevel, depending on the level of the invoking user.

    And: is this a good idea? Biba wouldn't have liked that a lot. And neither do I ;-)

    Concluding my observations mean:

    User downloads executable from internet, saves file to hard disk and this file has intlevel 'medium': maybe no a good idea.

    [maybe resulting from IE currently not assigning intlevels to files it writes]

    User running with admin_privs (most windows users will still sometimes do ;-) invokes this executable resulting in a process running with intlevel 'high': debatable...

    Security aware user labels some executables down to 'low' but invokes them as admin, process is running with intlevel 'high': what can I say here? ;-)

    These are some observations from a guy with some background on "Mandatory" security models, running Vista for the first time.

    Thanks in advance for your answer, I appreciate your efforts.



  • I believe that Trusted Solaris by Sun was the first commercial implementation of Mandatory Access Control.  I always thought this was a great feature and oddly neglected by the media.  I guess that now M$ does something, everyone will get excited...

  • Hi Steve,

    Enno posted very interested observations.

    Is there already some documentation that describes the behavior and scenarios of MIC?

    Or - alternatively - could you comment on Enno's findings as they look like a complete description of the current behavior.


  • PingBack from

  • PingBack from

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment