Review: Windows 7 AppLocker – Part 1: Overview

Michael PietroforteMVP By Michael Pietroforte - Thu, January 22, 2009 - 6 comments google+ icon

Michael Pietroforte is the founder and editor of 4sysops. He is a Microsoft Most Valuable Professional (MVP) with more than 30 years of experience in system administration.

New on 4sysops: AppLocker tutorial with tips and tricks

AppLocker is a new feature of Windows 7 that allows you to restrict program execution via Group Policy. It is comparable to—but better than—the Software Restriction Policies of former Windows versions, which are still supported in Windows 7 and Windows Server 2008 R2. Software Restriction Policies are not very popular among admins, because configuring them is time-consuming although it can easily be circumvented. AppLocker promises to address both downsides to Software Restriction Policies. In this article, I will give an overview of the capabilities, and in my next post, I will explain how to use AppLocker.

AppLockerAppLocker supports three types of rules: Path Rules, File Hash Rules, and Publisher Rules. Path Rules and Hash Rules are already available as part of the Software Restriction Policies.

Path Rules enable you to restrict the execution of programs to a certain directory path. For example, you can allow end users to launch applications only from the Windows Program Files folders. This is safe as long as end users are not allowed to install programs. The problem with this rule type is that users often also need to start applications from other locations—for example, from a file server. Depending on the complexity of your environment, it can be time-consuming to keep track of legitimate program folders.

Hash Rules use a cryptographic hash of the executable to identify a legitimate program. The major downside of this rule type is that you have to modify the rule whenever you update the program, because any kind of change to the executable will also change the hash.

AppLocker-Digital-SignaturePublisher Rules identify an application based on a digital signature of the application that was issued by the publisher. They are comparable to the Certificates Rules found in the Software Restriction Policies. However, Publisher Rules are more sophisticated. Most newer applications have a signature that can be used for Publisher Rules. In Vista and Windows 7, you can view this signature through the file properties of the executable. Certificates Rules usually work only with ActiveX controls that have an appropriate certificate, and these are very rare.

AppLocker-Create-Executable-Rules2 Furthermore, Publisher Rules have more options than Certificate Rules. They allow you to work with different scopes. You can restrict the execution of a program to the publisher (for example, Microsoft), to the product name (Internet Explorer), to the file name (iexplore.exe), or to the file version (8.0.0.0). Note that the file version does not necessarily correspond with the program version. It is also possible to restrict the rule to a specific version only, to a specific version number and above, or to specific version number and below. Because AppLocker gets this information from the digital signature of the executable, end users can’t circumvent Publisher Rules by just renaming a file.

All three rule types (Path, Hash, and Publisher) can be applied to executables (.exe), to scripts (.ps1, .bat, .cmd, .vbs, .js), to installer files (.msi, .msp), and to system libraries (.dll, .ocx). The latter option is not yet implemented in Windows 7 Beta1 (build 7000).

AppLocker-User-Group All rule types allow you to configure exceptions. An exception can be one of the three rule types, and it can be a different rule type from the rule it belongs to. For instance, you could configure a Path Rule that allows the execution of all apps in the Program Files folder except those of the publisher Microsoft. This would prevent users from launching Internet Explorer, Windows Media Player, etc. Or you could restrict the rule to a certain user or user group. It is also possible to configure ‘allow’ and ‘deny’ rules. According to my tests, it seems as if ‘deny’ rules may have a higher priority than ‘allow’ rules.

Part 2 of my review of AppLocker will offer some practical tips based on my experiences. For now, I recommend that you wait to test AppLocker until you have read my next post. It will save you some time.

-1+1 - Rate this post
Loading ... Loading ...
Disclaimer
Your question wasn't answered? Please ask in the new 4sysops forum!

6 Comments- Leave a Reply

  1. Christoph says:

    Excellent roundup, kudos!
    Yes, software restrictions are a pain to establish, this however looks very promising und useful.

  2. Simon Bishop says:

    The deny rules overriding allow rules sounds like an extension of NTFS permissions, where No Access means No Access…

    I can feel a whole layer of pain coming on!

  3. Christoph, thanks.

    Simon. You are right it is comparable to the NTFS permission. Actually, it is common practice in security that deny rules override allow rules.

  4. [...] jauh tentang AppLocker dapat dilihat disini http://4sysops.com/archives/review-windows-7-applocker-part-1-overview/   Share this post: | | | | Published Jun 16 2009, 12:35 PM by Fajar Filed under: [...]

  5. Grayda says:

    Now, I wonder if this lets you block SWF files too. Software Restriction policies are fantastic and AppLocker seems to be much better, but it’s not as fantastic as I’d like. Still, I’ll wait and see what’s going on..

Please share your thoughts in a comment!

Login

Lost your password?