NTFS Secrets

Controlling user access to files and folders on a Windows system is a complicated process and requires a sophisticated mechanism to keep everything secure. The NTFS security model provides this mechanism and allows for strict control over how users read, write, and otherwise manipulate files on a system.

The complexities of NTFS permissions can be overwhelming, even for experienced administrators. Sometimes you set file or directory permissions and simply don’t get the results you expected based on what you've learned from classes or manuals. Let's look at some little-known facts about NTFS permissions that will give you a leg up in using these permissions to best advantage.

1. Stick with the 5 Standard File Permissions
NTFS provides 14 special permissions that determine exactly how a user can access a file. These permissions get very specific, so to simplify things, NTFS groups the 14 permissions into 5 standard—or generic—permissions, as Table 1 shows. These standard permissions, for example, let you grant a user Full Control to a file rather than having to grant each of the 14 special permissions.

Although the standard permissions are convenient most of the time, the more specific permissions can have powerful security benefits. Consider the case of an audit log file. You might want to allow an application to append new entries to the end of the file but prohibit the modification of existing data to preserve the integrity of previous entries. To support this scenario, NTFS distinguishes between writing to a file versus simply appending data to the end.

From a command prompt, you can test the difference between writing to and appending a file. To write to a file, type this command:

C:>echo "new text" > test.txt

If you open test.txt in Notepad, you can see that it contains the line “new text”.

Alternatively, to append to a file, you can use this command:

C:>echo "Line 2" >> test.txt

If you open test.txt in Notepad now, you'll see that it contains two lines:

"new text""Line 2"

Unfortunately, you can't often take advantage of these fine-grained permissions. Let me demonstrate why this is the case. NTFS understands the difference between writing and appending, so you might want to try setting permissions to allow append but deny write access. To do that, set test.txt's permissions to allow everything but Write Data, as Figure 1 shows.

These settings should allow you to add to the end of a file but prevent you from changing existing data in the file. However, if you now try to append data with this command:

C:>echo "Line 3" >> test.txt

you'll be denied access. In fact, you now can't write or append to this file from the command prompt. Furthermore, if you try the opposite and allow Write Data but deny Append Data, you'll find that doesn't work either. In other words, if you deny one, you also deny the other.

At first glance, it might appear that the permissions are broken and don’t work as advertised, but that isn't the case. When writing code to access files, programmers need to request permission from Windows to act on a file.

Some software developers are diligent in specifying the exact permissions needed for any particular operation, and others are completely lazy and always ask for Full Control no matter what their code is doing. Most often, programmers request either standard Read or Write access, which works OK for most purposes. The problem with this is that your ability to enforce NTFS permissions can be only as granular as the requests the programmers use.

In the example above, the programmers who wrote the command-line redirection code requested the standard Write permission instead of distinguishing between writing to a file and appending to it. If you look at Table 1, the standard Write permission includes six of the more specific permissions. If a user doesn't have each of these six individual permissions, the request for standard Write will fail. That's why denying Append also denies Write.

So, although NTFS does provide fine-grained permissions, actually being able to implement these permissions is limited by whether software developers get that specific in their code. You might want to be extra vigilant and set very specific permissions on files, but it's usually a waste of time to get any more specific than the five standard permissions.

2. Be Aware of 2 Exceptions to Protection from Permissions Inheritance
The inheritance model that NTFS uses for access control plays an important role in determining who can access a file. To determine permissions, Windows must look at the ACLs that affect the file. Any file or folder has its own ACL that can allow or deny access to specific users and groups, but the object might also inherit permissions from its parent folder or any combination of folders above that. All these permissions could potentially conflict with each other—one ACL might allow a user to access a file, while another might specifically deny it. Furthermore, a user could be a member of multiple groups that have different permissions.

To resolve conflicting ACLs, Windows uses a basic set of rules:

To process these rules, Windows first looks for an access control entry on the object itself that specifically says it can either deny or allow a user access to a file. If Windows doesn’t find anything, it looks to the parent folder and continues on until it finds an access control entry that either specifically denies or allows access.

You can protect an object from the inheritance process by going to the Advanced Security Settings dialog box's Permissions tab and clearing the Allow inheritable permissions from the parent to propagate to this object and all child objects check box, as Figure 2 shows. If you do this, parent folder settings will no longer affect the security of the current file or folder or any files or folders below it—most of the time.

Two relatively unknown exceptions to this protection from permissions inheritance can lead to confusion. The first is that denying Read Attributes access to a file has no effect if the parent folder allows listing the directory. Even if you specifically deny users Read Attributes permission, any user that can list the directory can also view any file attributes in that directory. This exception obviously breaks rules 2 and 3—it lets an allow entry take precedence over a deny entry and lets a parent folder's permission take precedence over a restriction on the object itself. This exception also breaks rules 4 and 5 because even if you specifically protect a file from inheriting permissions by clearing the Allow inheritable permissions from the parent to propagate to this object and all child objects check box, the parent folder still affects the object’s permissions.

The second exception is that denying the Delete permission on a file or folder has no effect if the parent folder allows the Delete Subfolders and Files permission. Because most folders allow Delete Subfolders and Files permission by default, denying Delete on a file will rarely have any effect. This exception can lead to confusion because you might deny someone the ability to delete a file, yet find that he or she can still delete it. This exception breaks several inheritance rules, and again, it's true even if you specifically protect a file from inheriting permissions from its parent folder.

To make things more confusing, you might think that because allowing the Delete Subfolders and Files permission on a folder lets users delete subfolders and files, denying that permission would prevent users from deleting subfolders and files. But that's not the case. Denying the Delete Subfolders and Files permission on a folder essentially enables the ability to use the Delete permission on any child objects. You can't use either the Delete Subfolders and Files permission or the Delete permission alone to prevent file deletion. Protecting a file from deletion is a two-step process—first deny Delete on the file itself, then deny Delete Subfolders and Files on the parent folder.

If you had to read this section more than once to understand it, you'll probably agree with me that inheritance and its exceptions are way too complicated.

3. The Execute File Permission Can Come in Handy
Earlier, I said that fine-grained permissions aren't worth the effort, but I would make one exception: Execute File. One of the standard permissions is Read and Execute, but in fact, a user doesn't need Read access to execute a file. In most cases, all a user needs to execute a file is Execute and Read Attributes access. Furthermore, you typically don’t even need to give the user Read Attributes access because he or she will automatically get it from the parent folder, as I mentioned earlier.

It’s important to note that some specific programs might require the ability to read data in an executable or read extended attributes of that executable, but these programs are an exception. Also, side effects of removing Read access are that users won't be able to view version information or other properties of the file and that Windows Explorer won't show the program’s icon properly because Explorer won't be able to read the icon from the file.

Nevertheless, there might be times when an executable contains sensitive information—such as a database connection string—that you don’t want others to be able to view in a hex editor. Another benefit is that without Read permissions, a user can't copy the executable to another location.

In the case of the Execute File permission, fine control can be useful. Keep in mind, however, that scripts and batch files work the opposite way—to run them, a user must have Read access but doesn't require Execute File permission. It’s interesting to note that denying Execute File permission on a DLL or OLE Custom Control (OCX) ActiveX component prevents users from using regsvr32.exe to register that component.

4. Some File Permissions Are Less Useful than Others
Some file permissions are less useful than others simply because other default system privileges override them. You can't, for example, deny the Take Ownership permission for users who have the Restore Files and Directories system privilege, which by default includes Administrators and Backup Operators, because these users have the Take ownership of files or other objects system privilege. You can take this system privilege away from Administrators, but being Administrators, they can take it right back again.

The Take Ownership permission is largely pointless because by default only members of the Administrators or Backup Operators group can take ownership of a file and anyone who is in one of those groups already has the Take ownership of files or other objects system privilege. The only situation in which this permission would apply is if a user or group isn't a member of the Administrators group, doesn't have the Restore Files and Directories system privilege but does have the Take ownership of files or other objects privilege, and you want to deny the user or group the ability to take ownership of a specific set of files. In this one case, the Take Ownership permission will work as expected; otherwise, don’t bother with it.

The Read Permissions and Change Permissions special permissions don't apply to the file’s owner, even if you explicitly deny these permissions. Therefore, these permissions also don't apply to any user with the Take ownership of files or other objects privilege. If you want to deny Read Permissions or Change Permissions, you must also deny the ability to Take Ownership.

Note that although Read Permissions and Change Permissions don't specifically allow or restrict access to audit settings (i.e., the system ACL—SACL), most methods of viewing permissions—such as the Security tab on the properties dialog box in Windows Explorer—won't show the SACL if the permissions (i.e., the discretionary ACL—DACL) aren't available.

Finally, you probably don’t need to ever bother changing the Traverse Folder permission because by default every user on the system is given the Bypass Traverse Checking user privilege, effectively neutralizing that permission. Furthermore, Microsoft has long recommended not enforcing traverse checking because it has been known to cause problems with applications that don’t properly handle directory traversal errors.

5. Share Permissions Supplement but Don't Replace NTFS Permissions
When you set permissions on a file share, those permissions work independently from but in conjunction with the NTFS permissions on the underlying files and folders. Windows considers both sets of permissions and uses the more restrictive of the two.

Of the two sets, the NTFS permissions are more important. While share permissions control access to files accessed through network shares, they don't prevent users from accessing those files directly on the system or via Terminal Services. You should always rely on NTFS permissions for access control and use share permissions only to provide further restrictions for network users.

It’s also important to note that the permissions on each share affect only that share—they aren't inherited by or propagated to any separate share, even one located lower in the same physical directory structure. For example, say you have a share for all users mapped to D:users. All users can access this share and all objects below it. Now suppose you create an administrators-only share at D:usersadmin. This second share, although it's nested under the first share, has no connection to the first share. Even if you deny regular users access to the D:usersadmin share, they could still access the folder by going to the D:users share and changing to the admin directory. You would need to set the proper NTFS permissions to prevent users from accessing the admin directory. Typically, it's best to avoid nested shares to prevent these situations.

6. Tie Permissions to Built-in Groups
When you set permissions for files and folders, don’t forget to take advantage of the many built-in groups that Windows automatically assigns users to depending on how they log on to the system. There is, for example, a group for Remote Desktop Users. You could set very specific NTFS permissions based on the type of logon. You might, for example, want to give access to certain sensitive files only to an Administrator or to someone who physically logs on to the local console. You can do this by allowing access only to the Administrators and the Interactive Logon Users groups. You could also restrict certain files so that they're accessible only to accounts logged on as Services. See "Well-known security identifiers in Windows operating systems," http://support.microsoft.com/kb/243330, for a complete list of built-in security principals.

(See also "Understanding Well-Known Security Principals, Part 1," November 2005, InstantDoc ID 47857, and "Understanding Well-Known Security Principals, Part 2," December 2005, InstantDoc ID 48316, for more information about built-in security principals.)

7. Be Careful with Everyone
This brings me to my final tip: Be careful with the Everyone group. In Windows versions before Windows XP, the Everyone group includes anonymous users by default, so the advice has always been to deny access to Everyone. In XP, Windows Server 2003, and Windows Vista, the Everyone group doesn't include anonymous users by default, so depending on your specific permissions, denying access to the Everyone group doesn't specifically deny access to anonymous users. The safest way to prevent access by anonymous and other unwanted users is not so much to deny these groups permissions but rather to allow access only to specific users and groups.

NTFS permissions are complicated, but knowing these secrets can help you out of some very confusing situations in which NTFS just doesn’t work the way you think it should. For more information about NTFS and share permissions, see “Navigating the File System Permissions Jungle,” January 2006, InstantDoc ID 48495.