If you missed the first part in this article series please read:
In the previous part of this article series, I began explaining what the various User Account Control related group policy settings do. Although Windows Vista and Server 2008 offer hundreds more group policy settings than what were available in Windows XP and in Windows Server 2003, the User Account Control settings are among the most important of the new settings since they can act as one of a computer’s primary defenses against malware. In this article, I will continue the discussion by explaining the remaining User Account Control Settings.
User Account Control: Only Elevate Executables that are Signed and Validated
If you really stop and think about it, the main reason for having the User Account Controls in the first place is to prevent untrusted code from running on network workstations. Of course this raises the question as to how you can decide whether or not code should be trusted.
One common way of deciding whether or not code should be trusted is to look at the code’s digital signature. Many (but not all) software publishers digitally sign their code in order to prove that the code was created by the publisher, and not by someone trying to spoof the publisher’s identity. The digital signature also proves that the code has not been altered since it was signed.
Just because a piece of code is signed doesn’t necessarily mean that the code is trustworthy. It is still up to you to decide whether or not you trust the publisher that signed the code. As you make decisions regarding which publishers you trust, those publishers can be added to the Windows Trusted Publisher Store.
This is where the User Account Control: Only Elevate Executables that are Signed and Validated group policy setting comes into play. When enabled, this group policy setting performs PKI signature checks against any interactive application that requests elevation of privileges. If an application is signed by a trusted publisher (the publisher is listed in the Trusted Publisher Store) then the elevation of privilege request is authorized. If the code is unsigned or is signed by a publisher who you have not chosen to trust, then the elevation of privilege request is denied.
One thing to keep in mind is that according to the Microsoft documentation, this group policy setting only applies to interactive applications. That means that things like services and scripts that run invisibly, behind the scenes are not affected by this policy setting if the documentation is correct.
User Account Control: Only Elevate UIAccess Applications that Are Installed in Secure Locations
This particular setting is a little tricky for anyone who isn’t a developer, but I will explain it as simply as I possibly can.
By now you know that when a user performs a task that requires administrative permissions, then Vista’s default behavior is to display an elevation of privilege prompt to the user. What you might not realize though is that Vista protects the dialog box containing the prompt from cross platform communications. That way, a malicious application can not simulate user input and grant the elevation of privilege to itself.
Although this dialog box and some of the other Windows dialog boxes (such as the one prompting a user to press Ctrl+Alt+Delete to log on) are protected by the operating system, there are some situations in which an application has a legitimate need to communicate with these otherwise protected dialog boxes.
In order to access these protected dialog boxes, an application must be designed to include a manifest file that includes the following attribute:
The problem with using this attribute within an application is that it allows the application to completely undermine some of Vista’s built in security. This is where the User Account Control: Only Elevate UIAccess Applications that are Installed in Secure Locations setting comes into play.
The idea is that you don’t want just any application to be able to use the UIAccess=true attribute. If you just blindly allowed this attribute to be used, then malware authors could use the attribute within malware as a mechanism for exploiting your system. A better approach is to only allow trusted applications to use this attribute. One way to make sure that happens is to only allow applications to use the UIAccess=true attribute if they are located in a secure location.
There are only a few locations that Windows treats as secure. These include \Program Files and \Windows\System32. 64-bit versions of Windows also treat the \Program Files (x86) folder as being secure. Subdirectories beneath any of these locations are also treated as being secure.
User Account Control: Run All Administrators in Admin Approval Mode
You have probably heard people say that in Windows Vista, even administrators are treated as standard users. This is the group policy setting that makes that statement true. This setting, which is enabled by default, causes administrators to operate with a reduced set of privileges. Any time an administrator performs an action that requires the use of administrative privileges, the administrator is prompted to approve the elevation of privileges before the action is performed.
User Account Control: Switch to the Secure Desktop When Prompting for Elevation
If you have ever received an elevation of privilege prompt in Windows Vista, you probably noticed that the entire screen went dark, and that the only window that was not darkened was the elevation of privilege prompt. When a prompt displays in this manner, it is said to be displaying on a secure desktop.
The reason why Microsoft uses the secure desktop is because there are so many types of malware that create false Windows dialog boxes in an effort to trick users into clicking on something. When the operating system black out the entire desktop and display only an elevation of privilege prompt, it is designed to give users confidence that the prompt really is coming from the Windows operating system, and not from malware that is impersonating an operating system prompt.
By default, elevation of privilege prompts are always displayed on a secure desktop. You can disable the secure desktop though, by disabling this group policy setting.
User Account Control: Virtualize File and Registry Write Failures to Per User Locations
The last of the User Account Control settings is the User Account Control: Virtualize File and Registry Write Failures to Per User Locations setting. You have probably heard people say that a lot of applications that ran well under Windows XP and older versions of Windows do not run in Vista because of the new security features. Often times this statement is true because a large number of legacy applications assume that the user has full control over the local operating system. In Windows Vista even administrators are not treated as administrators by default, and this causes a lot of applications to break.
To get around some of the problems associated with the new security settings, Microsoft created this group policy setting. The basic idea is that legacy applications tend to write data to now forbidden areas of the file system and registry. When this group policy setting is enabled (it is enabled by default), those writes are intercepted and redirected to a different location. This allows legacy applications to run without compromising the operating system’s integrity.
As you can see, the User Account Control settings are critical to maintaining Vista’s security. In Part 5, I will continue the series by exploring some of the other areas in which Microsoft has made changes to group policy settings.
If you missed the first part in this article series please read: