Windows 7 : Interacting with the Built-In Security Features - ACCESSING APPLOCKER (part 1) - Seeing the AppLocker Entries in the Registry

AppLocker provides a significant new means of enforcing application execution policies. The emphasis is on code rights, not user rights as it is with NT security. You can attach AppLocker rules in a number of ways. For example, you can create AppLocker rules that affect a particular user or group. AppLocker rules can also affect an executable's publisher or even the version of a file. It's also possible to restrict particular application types.

AppLocker doesn't work with all versions of Windows. In fact, you're limited to the following versions:

• Windows Server 2008 R2 Standard

• Windows Server 2008 R2 Enterprise

• Windows Server 2008 R2 Datacenter

• Windows Server 2008 R2 for Itanium-Based Systems

• Windows 7 Ultimate

• Windows 7 Enterprise

You can create AppLocker rules when working with Windows 7 Professional, but the operating system won't enforce the rules. So even though AppLocker is a marvelous new security feature, it does currently have some significant limitations. AppLocker does build on Software Restriction Policies (SRP) technology found in older versions of Windows, so you may have to rely on SRP for now and update to AppLocker later.

1. Seeing the AppLocker Entries in the Registry

The AppLocker entries are part of a GPO. Unfortunately, in this case there isn't a convenient COM object you can use to access the information you need. What you need to do in this case is view the data using a registry entry. In fact, there are commonly eight or more registry entries you could use, but only one of the multitude of registry entries is always in a known place in the registry, the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\SrpV2 key. Figure 1 shows how this key might appear on your system.

Figure 1. AppLocker relies heavily on the registry to store settings.

The SrpV2 key stands for Software Restriction Policy version 2, because that's what AppLocker really is. Beneath this key are four keys for DLL, executable, installer, and script files. Each policy key name appears as a Globally Unique Identifier (GUID), which is pronounced "gwid" (think of squid). Every policy has just one value, named Value. It consists of an XML description of the policy. Here's a typical example of a publisher policy.

<FilePublisherRule Id="2041dcc1-7677-41f6-863c-6b8bb5b1b2a0"
                   Name="My AppLocker Rule 2"
                   Description="Another sample AppLocker rule."
                   UserOrGroupSid="S-1-1-0"
                   Action="Allow">
  <Conditions>
    <FilePublisherCondition
      PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US"
      ProductName="MICROSOFT (R) VISUAL STUDIO (R) 2010"
      BinaryName="VSHOST32.EXE">
        <BinaryVersionRange LowSection="10.0.0.0" HighSection="*"/>
    </FilePublisherCondition>
  </Conditions>
</FilePublisherRule>

					  

Of course, the entry won't appear nicely formatted in the registry — it appears as a single line of barely readable XML. Some information, such as the Id, Name, Description, UserOrGroupSid, and Action attributes, remains the same for every entry. The contents of the <Conditions> element vary by the kind of exclusion you create. For example, a path exclusion only requires a <FilePathCondition> element that contains a Path attribute.

2. Configuring the AppLocker Demo Example

The AppLocker Demo example consists of a Windows Forms application. You need to add two buttons, List Entries (btnList) and Add Entries (btnAdd). The example also requires a list box for output, lstEntries. Because this example relies on the registry, you do need to add the following using statements, but you don't need to add any special references.

using Microsoft.Win32;
using System.Xml;
using System.Security;

Everyone can read the AppLocker entries, so you don't need to add a manifest if your only goal is to read the entries. However, only administrators can add new entries.