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:
- Trusted Installer. Objects labeled with the Trusted Installer security level have the highest possible level of trust and can modify the operating system (as the name implies).
- System. Objects labeled as System are generally services or objects that are part of the OS itself. The LocalSystem and NetworkService service accounts, for instance, run with the System integrity level.
- High. Administrators nominally run as High integrity, along with other advanced-user accounts like the Backup Operator or Cryptographic Operator. For most practical purposes, any code that runs in the High trust level can make changes to the operating system.
- Medium. This is the default trust level for non-administrative users and their associated data.
- Low. The "Everyone" account and any temporary Internet files are typically assigned Low trust.
- Untrusted. Anonymous or "Guest" accounts run as Untrusted.
The most basic restriction imposed 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:
- On a properly configured system, you should not have to deal with UAC prompts very often. In the course of the average workday, I see maybe one or two prompts. In fact, I have to deal with typing in my password to get back in after locking my workstation more often than I deal with UAC prompts!
- If you get a UAC prompt when trying to launch a regular application or a document, there's a chance you're looking at some kind of permissions issue that has little to do with User Account Control itself. I had this happen a few times when I manually copied a program (one that didn't need to be installed to run) into the \Program Files folder. Resetting the permissions on the copied folder to inherit from the parent made all well again.
- Leaving the UAC prompts on gives you a good feel for when they come up and when they don't. If you turn them off completely, then you have that much less of an idea of what actions are truly administrative.
- The protection provided by UAC justifies itself very quickly when it's needed. At one point I was given a UAC warning about a program that I suspected was malware when it tried to launch itself. It wasn't malware, as it turned out, but the fact that it was not supposed to be running and that UAC alerted me to this fact was what mattered. (The number of such false alarms has been extremely low: I counted that one and maybe one other such incident in the entire time I've been using Vista as a production machine, which is about nine months.)
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.
