Practice Cryptography!

Okay, usually I try not to use this forum to rant about and particular technology that's associated with a specific corporation. However, UAC (user account control) is a technology that gets this treatment, if only because Microsoft came so close to getting it right -- but fell far too short of the mark to be useful.

First, a little overview of what I understand about it:

UAC creates two user tokens for every logon by an administrator. The user's shell (usually explorer.exe) and all processes created directly by it get the standard, unprivileged, normal user account token. (Even if a piece of malware exploits a hole in the software running under this token, only the user's own files are subject to tampering. In order to get access to the administrative token, when UAC is enabled the user is prompted for permission to use it.

Next, UAC also allows for what are called "integrity levels", which are used to roughly classify applications into how much of an attack surface the application wants to expose. Access Control Lists can contain entries that specify the minimum integrity level that a process must have in order to write to the file or registry key, though reading values is always permitted. They are implemented as additional attributes (like group memberships) set in the token that the application is run with -- and the case of "no explicit integrity level" is treated as "medium" (protected operating system files are given "high" integrity level requirements, which are only assigned to the administrator tokens that UAC prompts the user for. Realistically, this means that the only usually-available IL's are "medium" and "low".

Internet Explorer running in Protected Mode runs with an Integrity Level of Low.

On 32-bit systems, there is an additional thing that Microsoft does when UAC is enabled, so that it can support badly-written software that could run on older systems. This is file and registry virtualization. What it does is provide every old program its own view of the registry and the filesystem, such that program can put their own things where the expect them to be, but only for that software running under that user account. It is implemented as a shadow mount with copy-to-shadow on write semantics.
Notably, it is not supported for 64-bit apps or in situations where the UAC user interface is disabled.

And now that I've explained what I know, it's time to state what's wrong with this setup, in my view.

First: virtualization. It should be supported more places, but not for backward-compatibility reasons. As an example of a situation that virtualization could help, we can look at the case of Mozilla Thunderbird and its Eudora-inspired next beta version... When you run the beta, it directly manipulates the settings that are used by the prior version. Since it's beta, it is prone to bugs in every part of it. This means that your working settings can be fubar'ed by the beta, causing a need to restore or recreate the settings that worked pre-beta.

Next, UAC relies on the digital signatures on software to ensure that it has not been tampered with. Since we can no longer rely on our software doing only what we think it should be, why can't we assign every application running under a given token context its own security identifier? This would allow for explicit management of what things can access what -- in such a way that the OS itself can use its well-honed ACL system to perform the access checks.

For this to work, there would need to be a means of allowing applications the means to request access to other applications' data stores, and possibly a "copy other app settings", "virtualize access to other app's settings", or "allow direct access to other app's settings" choice that the user can respond to. This would function a lot like the integrity level concept... In that certain processes that manipulate data stores directly could be given a "allow user-integral access by this app to all data stores" SID. (as an additional note, this cannot only be granted to Windows components, it must be allowable for any piece of software at anythng above Low integrity-level. Since the IL is designed to reduce the attack surface, it should be honored.)

In addition, things running at Low IL should always have virtualization turned on. This would allow Internet Explorer to install ActiveX controls solely for its own use, for example, without requiring that Protected Mode be turned off.

Application datastores should be viewed as OS-level objects -- not as "files" or "keys", but rather as specific settings locations.

Users (yes, even home users) need to be able to positively identify any app running, even if the app itself does not have a digital signature from its developer. This is so that software like City of Heroes can be granted its own configuration space, and so that the OS can grant a security ID to it. This can be accomplished by creating detached signatures, perhaps in separate NTFS file streams.

The base that UAC can provide is mind-bogglingly useful. However, its current implementation is not well-described in ways that users (especially home users) can understand, and is so different from what users are used to that they end up just turning it off. As well, the technology has gotten enough bad rap that the name is not going to inspire trust in those people who have turned it off ever again. It poses a very difficult-to-understand change in how the OS works, and even most developers I talk with just disable it because they have work to do... and they don't even have the 2 weeks to play with it that I have had to get even this much idea of what it does. Thus, Microsoft should retire the name when they revisit it.

Now, let's hope my iPhone doesn't eat this when I post it...

Labels: microsoft, security, uac