One thing I have always liked about NTFS security is the fine-grained control you have over file permissions. But this power comes at a price—you must understand a whole new world of acronyms, confusing metaphors, and expanded definition of words such as principal, trustee, and inheritance. To fully take advantage of file permissions you need to understand how the whole thing works and delve into the lower levels where there is no pretty user interface and no cushion between you and the inner working of windows. You know you are close to understanding NTFS file permissions when you stop talking about files and folders and instead refer to objects and containers.

So over the years I spent the time to truly understand the inner workings of NTFS permissions. I spent the time to learn about ACLs, ACEs, DACLs, SACLs, SIDs, RIDs, inheritance, protected ACL’s, trust, and impersonation. I can set an ACL purely through SDDL and I hardly have to refer to my cheat sheets anymore.

And what did I gain from all this time and research? Nothing. When I set file permissions now I really only care about four basic things: read, write, execute, and delete.

There are several reasons for this. For one, I learned the importance of simplicity. NTFS permissions are so complex that so far no one has come up with a good way to even visualize them. Sure, we have the security settings dialog box but you can’t just glance at a directory or directory tree and quickly see who can do what.

But the main reason I have abandoned complex permissions is because most of the time they just don’t work the way you think they would.

Take the Delete permission for example. Many Windows administrators know that you can Deny Delete on a file and yet you can still delete it. Why is this? Because the parent folder has a permission called Delete Child that lets you delete files even if you specifically protect a file from being deleted. Now I could write pages of reasons on why this is lame, but I’ll save that for another time. What it comes down to is that in order to prevent something from being deleted you also have to tell the parent folder to not allow child files to be deleted.

Essentially, the Delete Child permission breaks all the rules of NTFS permission inheritance. An allow overrides a deny and a parent object’s ACL overrides a child object’s ACL—even if the child is protected from inheriting from a parent.

But don’t make the mistake of thinking that denying child deletion on a parent actually prevents child deletion. It just prevents the overriding of the delete permissions on any child that denies delete permissions. Although Microsoft claims that this behavior is for Posix compliance, I seriously question the need for this permission at all. And if Posix compliance is so important, why is there still case insensitivity in file names, drive letters in the file namespace, no concept of setuid, ELF vs PE executables, and inconsistent traverse checking?

It doesn’t stop there. Another problem is the Read Attributes permission. This permission is ignored if the parent folder allows listing a directory. Yes, this does makes sense—if you can list a directory you should be able to list the attributes for files in that directory. Again, it makes me wonder why even have this permission? The only time you would actually use it is when you deny a user from listing a directory and don’t want them to be able to see a file’s attributes if they happen to already know a file name in that directory, and have read access to that file. Certainly this type of control could be shared between the List Directory and Read permissions.

Also useless are the Write Data and Append Data permissions. In theory these could be quite useful but most software—including windows—doesn’t get that specific when requesting write access. Most code simply requests the generic Write permission which includes both write and append.

Let me illustrate this. Create a file named test.txt and deny Append Data, allowing all other permissions. Now try this at a command prompt:

C:\>echo test >> test.txt
Access is denied.
C:\>echo test > test.txt
Access is denied.

Do you see what happened? Denying the ability to append data did work, but you also denied the ability to write data. Now try the reverse and allow everything but deny Write Data. Run the commands above again and you will get the same result. In other words in most cases, the Append Data and Write Data permissions will behave the same. It all depends on how the code requests access to the file. If the code requests the generic Write permission, it won’t distinguish between append or write. This is important because if the code does use the generic Write permission, denying either append or write will deny the entire operation so it’s best to never use those anyway. The Take Ownership permission is quite useless because that is controlled by system privileges anyway. You cannot deny the Take Ownership permission for Administrators or users with the Restore Files and Directories system privilege, such as Backup Operators. This is because these users have the system privilege Take ownership of files or other objects. Technically you could take away this right from Administrators, but an Administrator can put it right back again. If you think about it, this permission is mostly pointless because by default no one can take ownership of a file unless they are already an Administrator or Backup Operator. And if they are already in one of those groups, this permission has no effect anyway. The only situation where you could use this permission is if a user or group was not a member of the Administrators group, did not have the Restore Files and Directories system privilege, yet did have the Take ownership of files or other objects privilege, but you wanted to deny them the ability to take ownership of a specific set of files. In that case you would need this permission on the specific set of files, but what have you really gained?Read Permissions and Change Permissions are kind of strange. They do not apply to the file’s owner, even if you explicitly deny that these permissions. Therefore, these permissions also do not 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.

Finally, in most cases don’t bother changing Traverse Folder permissions, because by default every user on the system is given the Bypass Traverse Checking user privilege. 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.

The Read Extended Attributes and Write Extended Attributes permissions have no effect if the programmer requests the generic Read and Write permissions. In fact, you need to be careful with these because denying either one could cause the generic Read and Write access to fail.

So again, what have I learned from all this research? Don’t even bother with anything more than read, write, execute and delete.

Oh and don’t forget, denying Read to a file doesn’t prevent someone from being able to execute it.

Related posts

• No related posts.