Mandatory integrity control in Windows Vista

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.

Comments (27)

  1. Anonymous says:

    I picked up this post on Vista’s new Mandatory Integrity Control feature by way of Steve’s blog. The…

  2. Anonymous says:

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

  3. Anonymous says:

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

  4. Anonymous says:

    In Windows Vista, COM will read HKLMSoftwareClasses when the process has a integrity level &amp;gt; MEDIUM,…

  5. Anonymous says:

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

  6. Anonymous says:

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

  7. Mike says:

    Wow. This sounds great! Have you run into any major application compatibility problems because of it?

  8. blogCZSK says:

    I really like the concept of MIC, however I am missing one (I think quite important) thing – visual differential between applications in different MIC modes. Dont you know about something like explorer extensions, that will enable this???

  9. spatie25 says:

    I was reading the blog by Keith Combs covering the new ‘HTTP over HTTP’ feature on ISA2006. (

    This got me back to a brain breaker I am struggling for some time now.  I am very concerned about the way things are moving with remote communication in all its aspects.  It shows over the last few years that more and more vendors are adopting the approach to encapsulating all sorts of protocols in HTTP.  Of course this is a very tempting solution, as HTTP in many cases is about the only protocol that is allowed to travel across a company’s firewall.

    I remember a presentation on security, hosted by MS employees, were it was stated bluntly : don’t use VPN, it is a hole in your firewall, which is quite fair to me.

    Now, I wonder what the advice would be from the MS security experts on protocols that are ported over HTTP.  I try to understand what the risks could be, or why I should be rest assured that this is under control.  The way I understand it is that there is no defence against malicious code, encapsulated in an HTTP protocol other than a very performant firewall with state of the art statefull inspection and even then, I am told, it still is risky business.   On the why’s, I get various explanations that do not always comply with one another.

    Now, I understand that this IPsec solution, offered by ISA2006, is pretty nice in terms of setting up a secure P2P connection without the hassle of a VPN client.  But this is not the discussion.  What to think about an employee, trying to access the OWA servers from a public computer : no VPN, no IPsec, just a certificate and a password.  Once compromised, you can only but imagine what could go wrong.  And in this case we are ‘talking’ HTTP, plain simple (for the firewall that is).  

    What if that employee tries to do RDP over HTTP or whatever other traffic that could be routed over HTTP.  I am making to much fuzz out of nothing, or should we be careful in how we ‘adopt’ these new features?

  10. SomeDude says:

    Great article!

    What GUI and command-line tools can be used to see or edit the labels on sucurable objects?  WHOAMI.EXE shows my SAT’s label, but I don’t see anything different in REGEDIT, Windows Explorer, etc.


  11. Bryan says:

    Very interesting – but I feel a nagging dread as well.

    What tools will administrators have, so that they can see and edit the intergrity level of an object?

    What errors will mismatched integrity levels generate?

    What documentation exists- explaining exactly how integrity levels are assigned by the OS and/or installer programs? Does written data always inherit the integrity level of the user whose process wrote it? (Given the IEPM example it seems not?)

    This could be an excellent feature, but it’s going to need extensive documentation! Anything on MSDN yet?

  12. Multician says:

    Multics had it, back in the day.  And of course it was an option for almost every Unix vendor back in the 80’s.

  13. KJK::Hyperion says:

    I wonder, why didn’t you implement the "no read down" policy? not even as an optional flag for labels?

  14. steriley says:

    MIKE: No, I’m not aware of any app compat issues that MIC has caused.

    SPATIE25: A long time ago, I had the same lament as you. "It’s a bastardization of HTTP to make it into the univseral transport," I claimed. But I’ve changed my thinking there. Look for a blog post soon about why I think the trend is good.

    SOMEDUDE: Some SysInternals ( now display integrity levels: AccessChk and Process Explorer.

    BRYAN: MIC is automatic and doesn’t really require user or administrator tinkering. There’s information on MSDN about MIC; one interesting document describes how IEPM uses MIC (

    KJK: We want to keep MIC’s purpose simple: to control writes. "No read down" is more of a privacy control. You can implement something very similar by putting deny ACLs on resources — deny access to any principal whose integrity level is lower than the level of the resource.

  15. Rob says:

    Please, please do not confuse the mandatory ACCESS controls as described by Bell and LaPadula with the mandatory INTEGRITY controls as described by Biba. They are fundamentally different in the way they are working and in the way they allow and disallow access.

    Also, your statement on Vista being the first commercial OS to implement them is dead wrong. It may be the first consumer OS, but it most definitely is not the first commercial OS.

  16. steriley says:

    ROB: Hmm, I’m not exactly sure why you think I have confused them? I certainly understand the difference — and my post even includes links to Wikipedia articles describing the two models.

    Note that I mention MIC as a *form* of Biba. While MIC does enforce Biba’s no write-up restriction, it doesn’t enforce the model’s no read-down restriction. To do so is impractical for computer integrity controls. Consider that you, as a medium integrity user, would never be able to read data written by IE protected mode if MIC implemented no read-down.

    Plus, understand that Bell-LaPadula can’t be directly compared to access controls. If you were to do that, then you could never write data that principals with a lower access level could read. In other words, you could never create information that’s readable by, say, everyone.

  17. Rob says:


    You should reverse the matter, the Biba model is a form of MIC. Comparing the MIC as implemented to  Biba is pointless, since, as you point out, Biba describes no read down as a restriction, which the MIC implementation in Vista does not do.

    I find it a very puzzling implementation, why did Microsoft decide to have the operating system files unlabeled? (thus essentially sticking them at the same level as the user is?). It would have been no problem to have them at a higher integrity level… lower-level processes can still read from them.

    Regarding Bell-LaPadula, you bet they can be compared to access controls, ssince they *are* access controls. Just not the ordinary discretionary ones you have gotten used to. You got the point behing Bell-LaPadula right, the fact that principals with a lower access level can’t read data with a higher level is what you *want* in the situation for which Bell-LaPadula was designed (namely a military organisation).

    I have worked with operating systems implementing the full Bell-LaPadula and the full Biba model, and those operating systems provide mechanisms to circumvent those models in certain, wel known and audited places. Working on such a system can be  pain, but the assurance that processes are strictly separated is in some cases worth that pain.  

  18. steriley says:

    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.

  19. Rob says:

    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.

  20. steriley says:

    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.

  21. Mark Minasi says:

    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

  22. Walter says:

    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!

  23. Enno Rey says:


    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 BUILTINAdministrators


     R  BUILTINUsers

     RW NT AUTHORITYAuthenticated Users


     Medium Mandatory Level (Default)

     RW BUILTINAdministrators


     R  BUILTINUsers

     RW NT AUTHORITYAuthenticated 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 BUILTINAdministrators


     R  BUILTINUsers

     RW NT AUTHORITYAuthenticated 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.



  24. Milan says:

    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…

  25. Dominick says:

    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.