Non-Executable Windows Folders and File Shares

Screen shot of the permission dialog showing it set as described above.

This describes how to make Windows folders and file shares more secure by preventing executables from being launched without technical knowledge while still allowing normal read and write access for documents.

Security Comes First

When a new file is created in your standard Linux distribution, it is without the execute bit set. This means attachments from e-mails cannot be launched by tricking the user into opening it and for example fake anti-virus executables cannot be launched.

For some insane reason, when new files are created by Windows it does so with the execute permission enabled. This is one of the most overlooked weaknesses of Windows as it means un-trained users can take any executable, from any source, and clickety-click, they're hosed and something nasty has a foothold on your network.

Now, imagine if Windows did things the Linux way. That invoice for that order you don't remember paying, clickety-click "Access denied". How many of those users are then going to think:

Ah-ha I clearly need execute permissions here, nothing is fishy. I'll just save this attachment, right-click, Properties, Security, Advanced, Disable inheritance, find my group, Edit, tick Read and Execute, Apply, Apply, aaah my invoi... oh no it's a virus!

Quite simply, if the user knows how to do this, they know it's dodgy. If they don't know how to do this, they're going to ring IT. I see a lot of fanboy wars where Windows is claimed to be a glass house cracking under the strain of all the vulnerabilities. In reality, it's not the technical exploits, but the technical knowledge of the user base and this poor decision on security that combined, means Windows is a lot easier to infect.

Hopefully I have you convinced, as I consistently get looks as if I'm some conspiracy nut when I mention this topic.

Where might you apply this?

  • User home folders
  • User temporary folders*
  • Document/media shares
  • Anywhere that doesn't host executables

* If you want to have separate locations for different users, you can create a GPO policy to push a Registry key as described here.

What This Doesn't Do

Because of the way NTFS works, the owner has ultimate rights to any files/folders they create. This means if you're already infected, the malware can potentially disable inheritance and reset the permissions we'll set below, making the file executable for other users on the network. I've looked hard for a GPO or something to allow administrators to own new files, but alas, this seems to say it's not possible**. So what this doesn't do, is offer protection if you're already infected. What it does do is hopefully reduce the chance of getting that infection in the first place.

This does not protect you against Office macro viruses, they are not executable files. They are normal files that contain executable code that is run within the Office applications themselves.

** Those screenshots are from NT (or a horribly themed Win2k), so this may be possible and I just haven't found out how yet.

How to Apply the Permissions

The permission we're interested in is a joint permission: Traverse folders / execute files. In a default setup, this permission is applied to both files and folders, meaning when enabled, you can enter folders and execute files. We're going to split this out into two separate permissions, one that will work on folders only, allowing users to enter folders and another for files, that will have identical permissions, except for Traverse folders / execute files. Once done, any files created in the folder will not be executable, but can still be read, written, and copied to another location that does allow executing.

In your organisation, you likely have many levels of existing permissions, so you will need to be careful. The guide below will show the principle of this using a new folder with default permissions inherited from C:. I will be removing the Authenticated Users priniciple for simplicity. If you want to keep it, you apply the same permissions to Authenticated Users as we're about to apply to Users (which includes Domain Users).

  1. Create a new folder, I'm going to be super-fun and use C:\New folder
  2. Right-click on the folder and choose Properties and click onto the Security tab
  3. Click the Advanced button, you should now see all the permission entries
  4. Click on Disable inheritance and convert the permissions to explicit
  5. For simplicity, we'll remove the Authenticated Users entry, select it and click Remove
  6. Select the Users principle and click Edit
  7. Reduce the scope of the existing permissions to folders only:
    1. Change Applies to from This folder, subfolders and files to This folder and subfolders
    2. Click Show advanced permissions in the top right of the permission panel
    3. Apply any other permissions you want, writing, folder creation/deletion etc.
    4. Click OK to return to the Advanced Security Settings dialog
  8. Create another reduced scope permission for files:
    1. Click Add to create a new permission entry and click the Select a principle link at the top
    2. On the dialog that appears, click the Locations... button and set it to the local host name (the top item) and click OK
    3. In the Enter the object name to select box, type Users and click Check Names followed by OK
    4. Make sure the type is set to Allow and Applies to is set to Files only
    5. Click Show advanced permissions and tick as necessary
    6. Unselect Traverse folder / execute file and click OK to return to the Advanced Security Settings dialog

Check the permission entries list on the Advanced Security Settings dialog, you should have two entries for Users, 1 applying to This folder and subfolders, the other applying to Files only.

Screen shot of the folder security settings dialog showing both file and folder permission entries.

If you're happy with this, click Apply followed by OK. Your users should be able to place any executable in the folder, double-click and get an access denied message.

Screenshot of the permission entry dialogs as I have it set:

You can drop any executables in there, and you cannot execute them:

Screen shot of the Windows access denied dialog when trying to launch the note pad executable from the configured folder.

You can still read and copy the files so users can continue to use their documents as they did before:

Screen shot showing the note pad executeable in note pad plus plus.