Navigating the File System Permission Jungle

Windows controls how users access files and folders through a detailed and complex system of permissions. In fact, Windows has one of the most granular object-access control mechanisms of any popular OS. Files and folders have at least 14 NTFS permissions that can be allowed or denied—and audited. You can set these permissions on a per file or folder and per user or group basis. You can also set permission inheritance on a per file or folder and per user or group basis. It's easy to get bogged down in a quagmire of permissions complexity. Here's a quick guide to how Windows file and folder permissions work and how to use them more effectively.

Object Access Basics
A user never directly "touches" any Windows object. All object access is done through programs (e.g., Windows Explorer, Microsoft Office) or processes. A program accessing a local resource on behalf of the user is called impersonation . A program accessing a remote resource is called delegation.

After a user logs on, the user's own System Identifier (SID) and group SIDs are collected by the lsass.exe process to create the user's security access token. Other information is added to the security access token, including the user rights assignments (also called user privileges), the user's session ID (unique for every session), a rights mask detailing the type of access being requested, and other information. You can see the user rights assignments by typing

WHOAMI /all 

When a program accesses a protected resource on behalf of a user, the Windows security reference monitor asks the program for the user's security access token. The security reference monitor then examines the token to determine the user's effective permissions and allows or denies the operation the user has requested. (I'll describe how effective permissions are arrived at in more detail in a moment.)

Share Permissions
Every protected object in Windows—including files, folders, shares, printers, and registry keys—has security permissions. Any Windows folder can be shared to allow remote access. You can set Share permissions on any folder or printer object in Windows, but the permission applies only when the object is accessed over a network share. Folder Share permissions are Full Control, Change, and Read.

Security principals given Full Control of an object can do nearly anything they want to the object. They can delete, rename, copy, move, and modify the object. Full Control also allows a user to change the object's Share permissions and take ownership of the object (if the user doesn't already have ownership and the Take Ownership privilege). This means that any user with Full Control can remove other people's—including the administrator's—permissions, (although the administrator can always reassume ownership and reassign permissions). The ability to change permissions is actually a requirement of any discretionary access control—DAC—OS such as Windows.

In most cases, the main access that nonadministrative users need to a share is Change permission. Change permission allows a user to add, delete, modify, and rename any resource in the covered folder. The Read permission allows a user to view, copy, rename, and print the object. A user with Read permission can often copy the object to a new location, and in the new location, the user has Full Control permission.

NTFS Permissions
If the Windows file system is NTFS (rather than FAT), all files, folders, registry keys, services, and many other objects have NTFS permissions. NTFS permissions apply whether the object is accessed remotely or locally. To view or modify a file or folder's NTFS permissions, simply right-click the object, choose Properties, then go to the Security tab.

Table 1 shows 7 summary NTFS permissions. These summary permissions are created by various combinations of 14 more-granular permissions, which Table 2 shows. You can view the more-granular permissions by clicking Advanced on the Security tab to open the Advanced Security Settings dialog box for the object, then clicking Edit on the Permissions tab. Reviewing the more-granular permissions of an object, even though it takes more effort, is a good habit to get into, especially for objects that need heightened security. The summary permissions sometimes don't accurately reflect the more-granular permission settings. For example, I've seen summary Read permission displayed when the user really had Read & Execute permission.

Similar to Full Control Share permission, Full Control NTFS permission gives a lot of authority to the holder. Nonadministrative users often have Full Control permission to their home directory and other files and folders. As I mentioned earlier, this permission level allows the holder to change the file permissions and take ownership, if they so choose. Instead of giving users Full Control permission, consider giving only Modify permission. (Then, if the user is the file owner, you can manually take away his or her ability to change permissions, if necessary.)

Note that NTFS permissions are technically known as discretionary ACL (DACL) permissions. Auditing permissions are known as system ACL (SACL) permissions. Most NTFS-protected objects have both.

The Effect of Windows Trusts
By default, all domains in Windows 2000 and later forests have a two-way transitive trust to all other domains in the forest. When a domain trusts another domain, all users in the trusted domain have the same security permissions in the trusting domain as the Everyone group and Authenticated Users group in the trusting domain. Because many permissions in any given domain are assigned to both those groups by default, a trust implicitly gives a lot of permissions that would otherwise not be granted. Be aware that unless you use a selective trust, any permission you give to the Everyone group or Authenticated Users group is also granted to every other user throughout the forest.

   Previous  [1]  2  Next