The rules in Privilege Guard are extremely flexible and can be used to elevate specific applications that trigger UAC or elevate all applications that trigger UAC. For instance, the screenshot below shows an application definition that will only fire when task manager attempts to launch with UAC.   

Task Manager Elevated

To capture all applications you would simply change the file name to *.exe and remove the publisher rule. Leaving the publisher rule in place would allow all operating system applications that trigger UAC to be elevated. Privilege Guard’s integration with Windows security catalogs enables the publisher rule to be used for operating system files, which are not signed directly by Microsoft. This topic was covered in a previous post. 

Privilege Guard can optionally prompt the user before elevating or running an application. In many situations you may want an application to elevate silently, without notifying the user. However, when the user is making a conscious decision to elevate an application it is often a good idea to prompt the user first. The screenshot below shows a policy that has been defined to elevate task manager when it triggers UAC. 

UAC Policy

In this example the task manager application has been added to an application group named All Signed UAC Apps. This would allow you to show a different prompt for signed and unsigned applications, as you may want the warning to be more severe for unsigned applications. You may even decide that a user is not allowed to elevate unsigned applications and indstead show the user a blocking message, which will prevent the application from launching.

The policy we have defined in this example will not elevate task manager until the user triggers a feature in task manager that requires administrator privileges, such as clicking the Show processes from all users button. When the user attempts to access an administrator feature in task manager then they will first be prompted with a message, as shown below. You may fully customize this message and even replace the banner with a corporate image. All of the text in the message is configurable, including full multi-lingual support. You may optionally ask the user for a reason or force them to re-authenticate, which have both been included in the example message below. 

UAC Replacement Message

The UAC rule is an extremely effective way of configuring specific or generic rules that only trigger elevation when an application requires administrator privileges. This effectively replaces UAC with a more flexible solution that is configured and mananged centrally through policy, without giving the user access to a local administrator account. Combined with the end user messaging capabilities in Privilege Guard the UAC rule can be used in a wide range of scenarios to elevate, block or monitor access to privileged applications and tasks on Windows 7 (or any other Windows operating system that supports UAC).

However, sometimes it is necessary to check the integrity of a file, and therefore most good application control solutions should provide additional capabilities for this purpose. In particular, you should expect a solution to provide support for both trusted publishers and file hashing.

A trusted publisher rule can be used to ensure that a set of application files have been signed by a specific vendor. If the vendor has not signed the application then the only other realistic option is to take a hash of the file, such as a SHA1. The only problem with file hashes is that they are difficult to maintain, as an update to an application will require a new set of file hashes. For this reason, checking the publisher is a much better approach, if the application has been signed, and hashes should only be used as a last resort.

This brings me on to Windows security catalogs, which is the subject of this post. If you check the properties of an application in the operating system, such as calc.exe, you will notice that the application is not signed by Microsoft. At first glance this would suggest that a publisher rule can’t be applied to operating system binaries, as they are not signed by Microsoft. Well that depends on whether your application control solution has built-in support for Windows security catalogs. All of the operating system binaries are indirectly signed by Microsoft. This is achieved by placing hashes of the operating system binaries into various security catalogs, which are then signed by Microsoft. If you’re interested in delving deeper then the catalog files can be found in C:\Windows\System32\catroot.

We built support for Windows catalog files into Privilege Guard 2.5 and the screenshot below highlights the publisher for timedate.cpl being identified as “Microsoft Windows” on Windows 7, even though the applet is not signed directly by Microsoft. On Windows XP the publisher will be set to “Microsoft Windows Publisher” for operating system binaries.

To understand the power of this capability, you could just as easily create a single rule to match any application binary that is signed by “Microsoft Windows”. This would be an extremely effective and secure way to whitelist all of the binaries that are part of the operating system, which would also include all future Windows updates.

So if you’ve ever wondered why the operating system files are not signed by Microsoft, now you know why, but more importantly I hope I have shown how application control solutions can provide a secure approach to identifying operating system binaries, which will require little to no maintenance of policies.