Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Is there a way to prevent Windows from ever running an unsigned binary? I realize that this would be a major pain from a user's perspective, but is there such of a mechanism in windows that would hold this policy?

share|improve this question
I bet that there are crucial windows binaries that are not signed, so including this option would seem to be suicide. It is entirely possible that I am wrong of course. – EBGreen Apr 11 '12 at 15:59
I figured that's why I hadn't heard of people doing that. This would be a big thing for servers. – monksy Apr 11 '12 at 16:00
Windows 8 on ARM will allow this through the requirement all Metro Applications must be signed. Its already possible to prevent a user from installing applications. As for not allowing unsigned binaries, no that won't be possible, and is not possible. – Ramhound Apr 11 '12 at 16:04
@monksy - How exactly would it be big? – Ramhound Apr 11 '12 at 16:05
If I'm not mistaken, a cert can get revoked. If a binary arrives on a server some how gets launched, you still want another layer to approve or deny it. – monksy Apr 11 '12 at 16:15
up vote 4 down vote accepted

It's not possible to restrict to signed binaries in general, as far as I know. However, if you wish to be able to define specific binaries and/or publishers (i.e. signed binaries from a specific vendor), that is possible. This can be done through AppLocker. Apparently it's only enforced in Windows 7 Enterprise and Ultimate, and Windows Server 2008.

While you can create AppLocker rules on computers running Windows 7 Professional, they will not be enforced on those computers. However, you can create the rules on a computer running Windows 7 Professional and then export the policy for implementation on computer running an edition of Windows that does support AppLocker rule enforcement.

Basically, it's set through Group Policy. I'll walk you through a relatively simple setup here.

  1. Open Group Policy editor (requires Professional, Enterprise or Ultimate). gpedit.msc in the start menu will do.

  2. Expand and navigate to Local Computer Policy > Computer Configuration > Windows Settings > Security Settings > Application Control Policies > AppLocker on the left.

  3. Create a new rule through the Action or right click menu. First, you'll want to create default rules. All executables in Windows and Program Files are allowed by default, use NTFS permissions to make sure only administrators (and system, etc, just not normal users) have write permissions to those folders, otherwise users could dump their unsigned executables in there and run them. We have to allow everything already in there, otherwise your OS will break.

    The default rule action is to run only those applications that are specifically allowed in the AppLocker rule collection. While there is no setting to configure the default rule behavior, you can use AppLocker's default rule collection to override the default rule behavior. To do this, create an allow rule with a path condition set to *. This configuration will allow all files to run. You can then create deny rules to block specific files.

  4. Create a the new rule. Use it to allow a publisher or file hash. You need an example for either of those.

    Quoting the Microsoft article's FAQ:

    • Publisher rule conditions can only be used for files that are digitally signed by a software publisher. This condition type uses the digital certificate (publisher name and product name) and properties of the file (file name and file version). This type of rule can be created for an entire product suite, which allows the rule in most cases to still be applicable when the application is updated.

    • Path rule conditions are based on the file or folder installation path of specific applications.

    • File hash rule conditions are based on the unique file hash that Windows cryptographically computes for each file. This condition type is unique, so each time that a publisher updates a file, you must create a new rule.

    • I wouldn't use path, unless write access is denied to those you are trying to block.
  5. I don't have a current installation of Enterprise or Ultimate to check on, but I believe you have to enable AppLocker, above the Executable Rules (Configure AppLocker Enfocement?).

An alternative method is to only allow unsigned executables to be run as a basic user, i.e. disable UAC elevation for unsigned files. This is also done through the group policy, User Account Control: Only elevate executables that are signed and validated.

This has the inherent weakness of users being able to self-sign files. Malware can also possibly be signed with a generic certificate, which is why AppLocker (and Software Restriction Policy for pre-7) is so much more secure.

share|improve this answer
Nice. I still don't understand how windows can get certified for security services without having signed internals. I need to learn more about SELinux someday. – monksy Apr 11 '12 at 18:06
I guess core Windows components would be signed but things like third party drivers could cause issues. – Bob Apr 11 '12 at 18:10

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.