This is part one of a two-part series on Windows Vista's security feature, integrity mechanism. Click here for part two of the series, detailing the process security shortcomings of the Vista integrity mechanism.
Most of the talk about new security in Microsoft Windows Vista focuses on User Account Control, or UAC. UAC itself, however, is simply one implementation of a deeper mechanism in Vista that allows for more precise control over objects and programs in Windows than before: the integrity mechanism.
The integrity mechanism, or IM for short, is a way to allow the system to treat applications that run in the same user account(s) with different grades of trust. Things that have been signed with a high grade of trust can't be modified by things that have a low grade of trust, even if they're both running as the same user. This puts an additional layer of protection around system files, as well as data used by key executables.
Keep in mind that this isn't a replacement for existing security mechanisms like access control lists, but something that works alongside them -- as a way to allow data, programs, objects and user accounts to be handled with an extra dimension of flexibility. It is not a cure-all for Windows security issues and isn't intended to be one, but the integrity mechanism does provide a more granular and intelligent way to lock down the way apps and data behave than has been traditionally provided in Windows.
Levels of integrity
IM uses six different levels of trust, or integrity, which it assigns to objects. Objects in this case means everything from files and folders to users and processes. Actually, user accounts and groups have levels of trust assigned to them out of the box, so that when a program runs in a given user account it will automatically have a trust grade assigned to it.
Here's a breakdown of the six trust levels, along with user accounts and groups that use them:
The most basic restriction imp
To continue reading for free, register below or login
To read more you must become a member of SearchEnterpriseDesktop.com
osed between levels of trust is what Microsoft calls the NO_WRITE_UP policy.
By default, no object of a given level of trust can modify any other object of higher trust.
Another trust policy you can implement is the NEW_PROCESS_MIN policy. It prevents a lower-trusted application (i.e., lower than you, the user or lower than the program invoking it) from running by default in anything other than its own lower level of trust. For instance, if you have a default-user command line running in the medium trust level, and you launch an executable that has been labeled as Low, the executable will not run as anything higher than Low trust. (In earlier versions of Windows, if you were running as a given user, everything you launched would run at the same level as you run regardless of what it was.)
Other seldom used policies include NO_READ_UP, which prevents a lower-level trust object from reading memory spaces for a higher-trusted object (which is not invoked by default, though), and NO_EXECUTE_UP, which allows a given executable to only be invoked by objects at its level or higher.
One important thing to understand is that objects that have the same level of trust have no restrictions on interaction with each other, at least not from the point of view of the integrity mechanism. For instance, all processes running with the Medium or non-admin user integrity level would be able to talk to each other and access data also labeled as Medium, unless you impose some other restriction on them.
UAC: One example of IM at work
I mentioned before that Vista's User Account Control is one implementation of IM. It's certainly the most obvious and the one that impacts the user most directly.
When you're logged in as administrator in Vista, the default behavior is to launch all your programs in a non-administrative context and with a reduced integrity level. This way, a program that tries to modify anything that's not on its own integrity level will be constrained from doing so. If a program needs to run as administrator for whatever reason -- e.g., an administrative application like the Device Manager -- you'll be warned about it via the UAC dialog and asked whether or not you want to proceed.
This makes it possible to run as admin in a workaday fashion without exposing the system to undue risks -- at the slight cost of having to explicitly confirm any administrative action you take. That said, Microsoft has tried to at least provide some degree of forewarning whenever you need to do this; actions that require admin privileges, like certain Control Panel icons, are flagged with the Windows "shield" logo.
It is possible to disable User Account Control and avoid the hassle of the prompts, but, in my opinion, there are several very good reasons not to disable UAC:
Look for part two later this month on SearchWindowsSecurity.com about the things Vista's integrity mechanism is not designed to do.
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.
