Testing Microsoft's Windows Application Whitelisting Tool - Page 2

To put SRP to the test, I set out to lock down a test desktop running Windows XP Service Pack 3 in such a way that only applications installed in the program files or system directories would be allowed to run. When paired with a limited-rights user account (as opposed to an administrator account), this SRP tactic will prevent executables stored in user-accessible places from running, thereby reserving all judgments over permitted applications to administrators.

On the XP machine I sought to lock down, I ran the secpol.msc tool to modify my system's local security policy. To make these changes through Group Policy, I would have used gpedit.msc. In the "Security Levels" folder within "Software Restriction Policies," I clicked on "Disallowed," entered its properties dialog and opted to make "disallow" my default on the system.

When I made this change, Windows automatically generated four exception rules for particular registry locations to prevent SRP from completely locking me out of my system. In addition to these, I added path-based rules that made my C:\Program Files and C:\Windows directories into free run zones.

I could have avoided granting this en masse permission to everything in my Program Files and Windows directories by calculating hashes of every application and library in those locations, but this approach could leave my system unusable in case of updates to those files. The new, patched applications and libraries would have different hashes than those they replaced, and as a result, the system would have prevented updated files from running.

I also adjusted the enforcement options to exclude administrators from enforcement and to include DLLs in my controls scheme-both of which differed from the system's defaults.

Another place where I diverged from defaults was in removing *.lnk, the file type for Windows shortcut files, as a blocked file extension. Without this change, none of the shortcuts in my start menu would have worked.

After I made these changes, I switched over to a limited rights user on my machine and tried to run the Firefox Web browser I'd previously installed. The application fired up without a problem. I then tried to run a copy of the handy SSH (Secure Shell) client, Putty, from my desktop-a restricted location under my SRP regime-and, sure enough, Windows informed me that the application had been blocked by policy, and that the system had logged the attempt in the event logs.

To make this controls scheme work, I had to add a rule to allow Microsoft's shortcut files, which are typically not installed in one of my policy-blessed locations, but are required for the Windows start menu to function properly. I made this adjustment with the extension-based controls.

Windows also offers the option of whitelisting libraries and applications based on the certificate with which they've been signed. This option can accommodate change more gracefully than does the hashing approach, as long as the files you wish to manage are actually signed. In Windows XP, few of the files that comprise the system are signed in this way, and many more applications, such as the Putty utility I mentioned above, also lack signatures. What's more, I found the certificate controls for the current iteration of SRP awkward to use.