Integrity mechanism has process security limitations

Click here to read the first part of our series explaining the Microsoft integrity mechanism: process security in Windows Vista.

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.

IM's limitations:

  1. 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.
  2. 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.

Microsoft Vista security extras
Windows Vista's little surprises -- by Mark Minasi

Secure removable storage devices via Group Policy in Vista

The second issue relates to the question of where the responsibility lies for Vista security and protecting the system. In Microsoft's view, that responsibility is diffused through many different mechanisms. Integrity mechanism, like the ACL system before it, protects one specific aspect of how the system is secured. It's meant to work in conjunction with other things, including high-level software that protects against malware -- like Windows Defender or a third-party antivirus package.

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.

This was first published in September 2007

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.