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.
Wow. This sounds great! Have you run into any major application compatibility problems because of it?
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???
I was reading the blog by Keith Combs covering the new ‘HTTP over HTTP’ feature on ISA2006. (http://blogs.technet.com/keithcombs/archive/2006/07/08/440752.aspx)
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?
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.
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?
Multics had it, back in the day. And of course it was an option for almost every Unix vendor back in the 80's.
I picked up this post on Vista's new Mandatory Integrity Control feature by way of Steve's blog. The...
Two weeks ago I delivered my Windows Vista System Integrity presentation at the TechEds in New Zealand...
In Windows Vista, COM will read HKLM\Software\Classes when the process has a integrity level &gt; MEDIUM,...
I wonder, why didn't you implement the "no read down" policy? not even as an optional flag for labels?
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.
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.
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.
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.