An Introduction to AppLocker (Part 5)

by [Published on 21 Jan. 2010 / Last Updated on 21 Jan. 2010]

Concluding the introduction to the AppLocker series by discussing the anatomy of an AppLocker rule, describing how to create rules both manually and automatically and how to modify existing rules.

If you would like to read the other parts in this article series please go to:

Introduction

In Part 4 of this series, I showed you the AppLocker rules that are generated by default, and talked about what each of those rules does. In this article, I want to conclude the series by showing you how to modify the default rules and how to create your own AppLocker rules.

The Anatomy of a Rule

The key to creating a new AppLocker rule or modifying an existing rule is to understand what the key components are that make up a rule, and how those components work together. After that, you can modify an existing rule by simply right clicking on the rule and selecting the Properties command from the resulting shortcut menu. From there, you can make the desired modifications and click OK. Likewise, you can create a new AppLocker rule by right clicking on a rule category and selecting the Create New Rule command from the shortcut menu.

When you create a new rule, Windows launches a wizard that walks you through the process. In contrast, modifying an existing rule involves manually editing the contents of the various fields on a properties sheet. In either case though, you are dealing with exactly the same set of options. That being the case, I want to talk about the various options and what they do.

If you look at Figure A below, you can see the properties sheet that is used whenever you modify an existing rule. The first two options on the properties sheet’s General tab allow you to assign a name to the rule, and to enter an optional description of the rule. Although entering a description is optional, I recommend being as descriptive as possible because as you begin to accumulate AppLocker rules, it can be tough to remember what each rule does.


Figure A: Each AppLocker rule must be assigned a unique name

The next set of options found on the General tab allow you to control who the rule will apply to, and whether or not that user or group should be allowed to run the specified applications. For example the rule shown in the figure above allows members of the built in Administrators group to run certain applications. To see which applications this group allows to run, we must switch to the Path tab, as shown in Figure B.


Figure B: The Path tab lists the path to which the rule applies

The properties sheet shown in the figure above only includes a Path tab because it pertains to a path rule. Had this been a publisher rule or a file hash rule, the name of the tab would be different. In any case though, this tab sets up the conditions for the rule. For example, in the figure above the path is described as *.*, which means any path. Therefore the condition that activates this rule is essentially “any path”. As you can see in the figure though, we could have just as easily specified a more specific path, or even an individual file.

The final tab on the properties sheet is the Exceptions tab. As the name implies, the exceptions tab, which is shown in Figure C, allows you to make exceptions to the rule. An exception can consist of a Publisher, File Hash, or a Path rule. For example, the AppLocker rule that I have been showing you is designed to allow Administrators to run any Windows installer file, regardless of its location. If we wanted to create an exception to the rule, we could set the rule up so that the Administrator is able to run any Windows Installer file unless it is located in the C:\Program Files\Games folder. Another variation might be an exception based on the file hash of the installer package for Grand Theft Auto. That way, an administrator could install pretty much anything that they need to, but they can’t install Grand Theft Auto.


Figure C: The Exceptions tab allows you to make exceptions to a rule

While I am on the subject of rule exceptions, I want to point out that sometimes exceptions work backwards from what I have just described. As you will recall, you can set up a rule to either allow or deny permission to run an application. When I showed you the deny option, you might have thought that it was a little strange to have a denial option when AppLocker’s default behavior is to deny access to anything that you have not explicitly granted users permission to use. The reason why the Deny option exists is because you can actually grant permissions by creating an exception to a Deny rule.

I know that this sounds confusing, so let me give you an example. Suppose that for some reason you wanted to block access to the entire Program Files folder (do not actually block this folder, this is just an example), but that you need for users to be able to run applications that are located in \Program Files\Microsoft. You could accomplish your objective by creating a rule that denies access to the \Program Files folder, but that lists \Program Files\Microsoft as an exception to the rule.

Automatically Generating AppLocker Rules

As you can see, AppLocker rules are not very complicated. Even so, once you start creating AppLocker rules, you have to authorize any application that you want users to be allowed to run. If you neglect to authorize an application, the users would not be able to run it. My point is that even though Microsoft makes it easy to create an AppLocker rule, creating a comprehensive set of AppLocker rules can be a lot of work. Thankfully, there is help.

AppLocker contains a mechanism for automatically generating the necessary rules. To access this feature, just right click on one of the rules containers, and select the Automatically Generate Rules command from the shortcut menu. When you do, Windows will launch a wizard that prompts you for the name of a file path to analyze, a security group that the newly created rules should apply to, and a name to assign to the set of rules. You can see what this wizard looks like in Figure D.


Figure D: Windows can automatically generate AppLocker rules

When you click Next, Windows asks you some questions about how the rules should be created. By default, Windows creates publisher rules for any signed applications, and file hash rules for all other applications. This is just the default behavior though. You have the option of creating other types of rules.

Once you have decided what types of rules you want to create, click Next and the rules will be generated. When the process completes, you will see a screen similar to the one shown in Figure E. As you can see, this screen tells you how many rules of each type were created. You also have the option of reviewing the files that were analyzed or of viewing the rules that were automatically created.


Figure E: AppLocker can automatically create large numbers or rules

Conclusion

Although AppLocker is a huge improvement over Software Restriction Policies, it is far from being a substitute for third party application management software. Even so, AppLocker rules do a reasonably good job of allowing you to lock down your desktops so that users are only allowed to run authorized applications.

If you would like to read the other parts in this article series please go to:

Featured Links