Problem solve Get help with specific problems with your technologies, process and projects.

Integrity mechanism has process security limitations

The integrity mechanism in Windows Vista is designed to assign levels of trust to processes running in your OS. However, there are some things that the IM is not designed to do. Read about these shortcomings and their implications in this tip from security expert Serdar Yegulalp.

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 and other TechTarget sites.

This was last published in September 2007

Dig Deeper on Microsoft Windows Vista operating system

Start the conversation

Send me notifications when other members comment.

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

Please create a username to comment.