Migration and Deployment: A look at Windows 8 AppLocker Part 19

One of the Technologies we introduced with Windows 7 was AppLocker.  AppLocker presented a great new way to control what applications could run on your desktop environments.  Now if this sounds familiar to what Software Restriction Policies (SRP) do for your environments, it is important to understand the difference between the two.  SRP are still supported and still helps to control applications in your environment.  They approach the challenge differently.  Fundamentally there are two ways of controlling applications:

• Block/Deny List: With this approach your create a list of all the malicious applications in the world and create rules to block them.  This approach is similar to antivirus programs.  As an administrator your would create deny rules for all the unwanted software that they would like to block within your business.  While effective, the challenge was keeping up with the malicious software and having to create a deny rule for each application.  This is essentially how SRP (in XP and Server 2003) worked, although you had allow or deny rules, it was still all based on the list
• Allow List: With this approach you create a list of all approved software that you need in your environment and create rules to allow only those applications and block the rest. In the allow listing mode you block all unwanted software by default and allow only those applications to run that have been explicitly allowed.  While this method is effective, the main challenge is you have to create a portfolio of applications for your environment.  AppLocker works in the allow listing mode.

 

AppLocker Overview

While SRP still can be used it did not provide a fine grained way to set up your lists, and maintain an effective SRP was very reactionary.  With AppLocker you can create more fine grain policies that survive application updates. AppLocker introduced an audit mode where you can test policies before actually enforcing them.  The types of rules and files that you can control with AppLocker are listed below:

Rule collection	Associated file formats
Executable files	.exe .com
Scripts	.ps1 .bat .cmd .vbs .js
Windows Installer files	.msi .msp .mst
Packaged apps and Packaged app installers	.appx
DLL files	.dll .ocx

 

You may have noticed a new option listed as Package Apps.  These are commonly know as  Windows apps, and can be installed through the Microsoft AppStore Packaged apps can be installed by a standard user unlike some desktop applications that sometimes require administrative privileges for installation. Typically, an app consists of multiple components – the installer used to install the app and one or more Exes, Dlls or Scripts. With desktop applications, not all those components always share common attributes such as the publisher name, product name and product version. Therefore, AppLocker has to control each of these components separately through different rule collections – Exe, Dll, Script and Windows Installers. In contrast, all the components of a packaged app share the same attributes: Publisher name, Package name and Package version. It is therefore possible to control an entire app with a single rule.

Depending on which type of application is executed AppLocker works slight different under the covers.  Whenever a user launches an executable, the system triggers a create process function. This function in turn triggers the kernel that takes the steps necessary to start the execution.   AppLocker driver intercepts that call. The driver is divided into two distinct parts. The first part computes the identity of the file being launched. Putting this in the context of Notepad at this point the driver determines that the user is trying to launch a file that is signed by Microsoft, belongs to the product Windows and has the name Notepad.exe. After computing the identify, the driver asks the question can I run this file? The second half of the driver looks up the rules database and determines whether there is an allow or a deny rule for this particular file. Based on this evaluation the driver either allows or denies the execution. A similar chain of events happens when loading a library. Every time an application loads a library the system internally triggers what we call the load library function. The AppLocker driver intercepts this function call and evaluates the rules based on the identity of the file being loaded.  In case of MSIs in script the evaluation happens in the user mode. Here the script host calls the user mode part of AppLocker to evaluate the rules. If the file being executed is denied, AppLocker returns an error code to the script host which in turn displays a meaningful error information to the user indicating the execution was blocked by admin policy.

When you create a rule for your application collections, you can allow or deny the application.  You also have 3 ways to control how you process the rule:

• Path: This rule condition identifies an application by its location in the file system of the computer or on the network.  One of the weaknesses is if the executable is moved the path is no longer valid.  This rule was also in SRP
• File Hash: When you choose the file hash rule condition, the system computes a cryptographic hash of the identified file. The advantage of this rule condition is that because each file has a unique hash, a file hash rule condition applies to only one file. The disadvantage is that each time the file is updated (such as a security update or upgrade) the file's hash will change. As a result, you must manually update file hash rules.  This was also in SRP
• Publisher: This condition identifies an application based on its digital signature and extended attributes when available. The digital signature contains information about the company that created the application (the publisher). Executable files, DLLs, Windows installers, Packaged apps, and Packaged app installers also have extended attributes, which are obtained from the binary resource. Attributes for executable files, DLLs and Windows installers contain the name of the product that the file is a part of, the original name of the file as supplied by the publisher and the version number of the file. In Packaged apps and Packaged app installers, these extended attributes contain the name and the version of the application package.

The true power of AppLocker are the publishers rules.  For example with one rule you could allow all Microsoft Office applications run, such a big improvement over SRP!  So creating rules is very straight forward once you know the applications you want to run.  The hardest part of the process is generating your application portfolio, that is where products like SCCM can really streamline the process.

8 Tidbits and Troubleshooting for AppLocker

1. You will find the AppLocker Policies in the Application Control policies in your Group Policy Objects.  However, when you first go to look at the policies you will not see the DLL rules.   You will have to enable these by default.  In application control polices Right Click on AppLocker and select Properties.  On the Properties tab click advanced and you will see where you can enable the DLL rules.

2. While Creating AppLocker rules is straight forward to do, you may notice the first time you create rules, they may not not work.  For AppLocker rules to be processed by your system, you first need to enable the Application Identity service.  By default this service is disable.  The Application Identity Service determines and verifies the identity of an application, when this service is disable it will prevent AppLocker from being enforced. 

3. The Automatically Generate Rules Wizard allows you to create multiple rules at one time. You can select a folder and let the wizard create rules for the relevant files within that folder, or in case of Packaged apps, you can let the wizard create rules for all Packaged apps that are installed on the computer. You can also specify the user or group to which to apply the rules. This wizard automatically generates Allow rules only.  Makes setting up rules quick and easy learn to use this powerful feature!

4. One question you may ask is does AppLocker impact performance? In general AppLocker rules do not have a noticeable impact on performance.  However, DLL rules have a small yet noticeable impact on performance. This is because AppLocker rules are evaluated for every single library that is loaded.

5. AppLocker is designed for enterprises where the end user runs as a standard user. Privilege users, such as local administrators, can nontrivially bypass AppLocker rules. This is true for most of the other security settings on the machine as well.

6. TEST, TEST, TEST, AppLocker is a great tool and you need to test this in a lab before rolling out in production.  Take a look at his set of articles for some great step-by-step guidance (while the article is from Windows 7 it is still applicable): AppLocker Step-by-Step Scenarios 

7. PAY ATTENTION TO THE DEFAULT RULES MESSAGE!   When you create your first rule you will be asked to create the default rules.  Please do so.  The default help ensures that system files will be allowed to run.  If you did not click yes, you create the default rules by right clicking on the rule collection and select Create Default Rules.  Here are the default rules that will be created:

Executable default rule types include:

• Allow members of the local Administrators group to run all applications.
• Allow members of the Everyone group to run applications that are located in the Windows folder.
• Allow members of the Everyone group to run applications that are located in the Program Files folder.

Script default rule types include:

• Allow members of the local Administrators group to run all scripts.
• Allow members of the Everyone group to run scripts that are located in the Program Files folder.
• Allow members of the Everyone group to run scripts that are located in the Windows folder.

Windows Installer default rule types include:

• Allow members of the local Administrators group to run all Windows Installer files.
• Allow members of the Everyone group to run all digitally signed Windows Installer files.
• Allow members of the Everyone group to run all Windows Installer files that are located in the Windows\Installer folder.

DLL default rule types:

• Allow members of the local Administrators group to run all DLLs.
• Allow members of the Everyone group to run DLLs that are located in the Program Files folder.
• Allow members of the Everyone group to run DLLs that are located in the Windows folder.

The Packaged app default rule types:

• Allow members of the Everyone group to install and run all signed Packaged apps and Packaged app installers.

8. Say you ignored the default rules and after reboot you cannot access your desktop.  Remember Safe Mode.   In Safe Mode the application identity service is not running, and you will be able to go in and disable the service and re-evaluate your AppLocker rules. 

 

Past that learn how to use this powerful ability to control your Windows 8 applications and if you want to go even deeper take a look at this article: AppLocker Overview