The goal is to prevent users from running unwanted programs on a terminal server.
I have read many articles from Microsoft and others saying that the new Applocker feature is 100% better than the old Software Restriction Policy and is recommended as a replacement of latter.
I am not sure to understand the real advantages of Applocker apart from the kernel mode execution.
The most of its functionnalities can be reproduced with Software Restriction Policy.
At the same it has one BIG disadvantage that make it pretty useless: it is not extensible, and you cannot add custom file extensions that you want to restrict.
What are advantages of Applocker over SRP and what would you recommend for software control?
Best Answer
Software Restriction Policy is deprecated by Microsoft (technet effectively claiming SRP is not supported), since Windows 7 Enterprise/Ultimate introduced AppLocker.
In practice SRP has certain pitfalls, for both false negatives and false positives. AppLocker has the advantage that it's still being actively maintained and supported. If AppLocker is an option then it could be the cheaper one - after accounting for your time and risks taken. It's also possible there's a suitable third-party alternative (but this question didn't include that option :).
Hopefully you'd gain perfect understanding of SRP's pitfalls before you fall into any of them
</sarcasm>
. Some of them are described in a nice security article from Vadims Podāns.Known pitfalls
\Windows
folder is permitted. Some sub-folders can be written to by users. Applocker is the same, but at least official documentation mentions this limitation."To enumerate all folders with users write access you can use, for example, AccessEnum utility from Sysinternals pack." (or AccessChk).
An NSA document gives 16 examples of folders to blacklist with SRP (although the registry path rules use backslashes incorrectly so must be corrected - see point on registry paths below) and warns about a common over-broad blacklist entry.
The obvious question is why aren't we carefully whitelisting individual paths under
\Windows
instead. (Including the\Windows\*.exe
legacy,System32\*.exe
, etc). I didn't notice any answers to this anywhere :(.%systemroot%
, SRP can be bypassed by users by clearing the environment variable. These are not used in the suggested defaults. However they may be tempting to use. This footgun is fixed in AppLocker, because it never looks at environment variables.\Program Files
used on modern 64-bit installs. When resolving this using the more secure "registry paths", there are reports of false denials in random situations, which could easily be missed in testing. e.g. see comments on SpiceWorks SRP howto. This is to do with 32-bit applications reading relevant paths from the WOW6432Node of the registry: resolution is to add both these paths to SRP to allow all programs to work on 32-bit and 64-bit machines as Unrestricted whether started from an x64 or x86 host process:%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%
wscript /e
... or maybe stuffing enough shellcode in an inline script parameter... etc.*.Extension
, with no warning. So you can't trust the official documentation, and it seems unlikely to get fixed now.Pragmatic approach
Software whitelisting is potentially a very powerful defense. If we get cynical: this is exactly why Microsoft deprecates the lower-priced versions and invents more complex ones.
Maybe no other option is available (include 3rd-party solutions). Then a pragmatic approach would be to try configuring SRP as simply as possible. Treat it as an extra layer of defense, with known holes. Matching the pitfalls above:
%systemroot%
.\Program Files\
directories are permitted on modern 64-bit machines. The extra "registry paths" you will need to add for\Program Files\
on 64-bit computers are%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%
and%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%
.\
with forwardslashes/
(e.g.%HKEY_LOCAL_MACHINE\Software\CompanyName\CustomApps%App/Bin/start.exe
)\\%USERDNSDOMAIN%\Sysvol\
. (See point #2, sigh, then see point #6).