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
Anonymous
January 01, 2003
I picked up this post on Vista's new Mandatory Integrity Control feature by way of Steve's blog. The...Anonymous
January 01, 2003
PingBack from http://puzzleware.net/blogs/archive/2007/11/04/Failure-creating-an-Outlook-application-object-on-Vista.aspxAnonymous
January 01, 2003
Two weeks ago I delivered my Windows Vista System Integrity presentation at the TechEds in New Zealand...Anonymous
January 01, 2003
Two weeks ago I delivered my Windows Vista System Integrity presentation at the TechEds in New Zealand...Anonymous
January 01, 2003
PingBack from http://xato.net/bl/2007/03/12/why-doesnt-ie7-protected-mode-mark-downloaded-files-as-low-integrity/Anonymous
January 01, 2003
In Windows Vista, COM will read HKLMSoftwareClasses when the process has a integrity level &gt; MEDIUM,...Anonymous
January 01, 2003
Two weeks ago I delivered my Windows Vista System Integrity presentation at the TechEds in New ZealandAnonymous
January 01, 2003
I have finally got my outlook unread messages down to zero. There are 1229 Messages in my deleted Items...Anonymous
July 23, 2006
Wow. This sounds great! Have you run into any major application compatibility problems because of it?Anonymous
July 24, 2006
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???Anonymous
July 26, 2006
The comment has been removedAnonymous
August 03, 2006
The comment has been removedAnonymous
August 03, 2006
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?Anonymous
August 28, 2006
Multics had it, back in the day. And of course it was an option for almost every Unix vendor back in the 80's.Anonymous
September 08, 2006
I wonder, why didn't you implement the "no read down" policy? not even as an optional flag for labels?Anonymous
September 10, 2006
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 (www.sysinternals.com) 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 (http://msdn.microsoft.com/library/en-us/IETechCol/dnwebgen/ProtectedMode.asp).
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.Anonymous
September 11, 2006
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.Anonymous
September 11, 2006
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.Anonymous
September 12, 2006
Steve,
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.Anonymous
September 12, 2006
The comment has been removedAnonymous
September 13, 2006
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.Anonymous
September 13, 2006
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.Anonymous
September 18, 2006
The comment has been removedAnonymous
September 28, 2006
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!Anonymous
October 06, 2006
The comment has been removedAnonymous
October 07, 2006
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...Anonymous
October 08, 2006
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. thanks!