2

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?

7
  • 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
    Commented Apr 11, 2012 at 15:59
  • 1
    I figured that's why I hadn't heard of people doing that. This would be a big thing for servers.
    – monksy
    Commented Apr 11, 2012 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
    Commented Apr 11, 2012 at 16:04
  • @monksy - How exactly would it be big?
    – Ramhound
    Commented Apr 11, 2012 at 16:05
  • 1
    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
    Commented Apr 11, 2012 at 16:15

2 Answers 2

4

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.

2
  • 2
    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
    Commented Apr 11, 2012 at 18:06
  • I guess core Windows components would be signed but things like third party drivers could cause issues.
    – Bob
    Commented Apr 11, 2012 at 18:10
0

Yes, verifier.exe. I would make sure to use verifier.exe /bootmode oneboot as an addition to anything you setup - as this will likely bluescreen the PC during boot, or immediately after the logon screen appears. Both situations can be remedied by disabling the verifier service in the registry if booted into recovery/winPE mode.

Also helpful is /volatile and /reset!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .