What IM won't do
There are a number of things that the integrity mechanism, or IM, has not been designed to address regarding Vista security, and they are things Microsoft talks a bit about in its own documentation. It may seem a bit technical at first, but I'll explain the importance.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
- No enforcement of "no-read-down" policies. A "no-read-down" policy would prohibit a higher-trust process from reading data held by a lower-trust process. One possible reason to do this would be to protect higher-trust processes from reading deliberately malformed data provided by a lower-trust process, as pre-emptive process security against things like buffer-overflow exploits. Windows assumes the burden of that kind of integrity-checking that rests with the application and not the operating system.
- No dynamic policies. This means that the integrity of a given object doesn't change if it opens objects of multiple levels of integrity. The example Microsoft cites is a high-integrity process that has several high-integrity object handles open, and then opens another handle to a low-integrity item. In Windows, the existing open handles stay at the same level of integrity. They don't all drop magically to the lowest level and they are not forced to close. (If they were forced to close, that would probably cause many existing application behaviors to break.)
These two limitations point toward two real-world issues. The first is making sure that existing Windows applications can still work relatively well in Vista, while still hewing to the new IM trust model for process security. Sometimes this means that a given program has to be launched as admin to run properly; only occasionally, as with low-level system utilities, does it mean the program has to be rewritten.
When User Access Control (UAC) was announced, many people declared that it wouldn't be of any use if a user was tricked into granting admin access to a piece of malware. Security researcher Joanna Rutkowska has talked about many of her own criticisms of UAC and IM. On the linked page, she describes a scenario where it's possible for a piece of malware to read (i.e., steal) data outside of its trust zone, since lower-trust programs are not barred by default from reading higher-trusted data.
I agree that this is a legitimate concern, but I am not sure if it is exclusively the province of IM to stop it from happening. One way to think about all this is that the responsibility for protecting the user against malware or data theft is not something exclusively shouldered by UAC, or IM, or any one security mechanism in the system. Integrity Mechanism's job is to make sure that an object that is not trusted by the system cannot access things that are trusted -- it's just one piece of a larger puzzle in which many other mechanisms all have a part.
Integrity Mechanism is no magic bullet, and is not meant to be one. It's not a substitute for proper programming practices or thoughtful systems administration policies. It's a framework from which better security behaviors for Windows -- better than the XP model, certainly -- can and have been derived. And one of its derivative technologies, UAC, has provided users with a way to run as administrator without automatically putting the system as a whole at risk.
About the author: Serdar Yegulalp is editor of Windows Insight (formerly the Windows Power Users Newsletter), a blog site devoted to hints, tips, tricks and news for users and administrators of Windows NT, Windows 2000, Windows XP, Windows Server 2003 and Vista. He has more than 12 years of experience working with Windows and contributes regularly to SearchWindowsSecurity.com and other TechTarget sites.