Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

Controlling Access to Files and Folders Using NTFS Permissions

You do not have to use the Windows NTFS file system, but you should. If you do, different permissions can be applied to every file and folder. This is not usually necessary or practical. Instead, if data files are organized in folders according to data sensitivity and by ownership, permissions can be set at the folder level and applied carte blanche to all subfolders and files. If there is a need to modify permission settings within this hierarchy, it can easily be done. The hierarchical nature of the file system allows file permissions set on a top-level folder to be inherited by the files and folders below it. Permission inheritance reduces the burden on the administrator.Chapter 3, "AuthorizationLimiting System Access and Controlling User Behavior," introduced the basics of object permissions and inheritance. This chapter will provide the details.

New in Windows Server 2003 are more secure volume root permissions, more secure default share permissions, and a change in the location of security descriptors.

File and Folder Permissions

Configuring file permissions for files and folders is easy; determining the appropriate permissions you should set is not. Two problems exist: understanding the large number of permissions that can be set, and deciding which Windows groups should have which permissions. The latter must be determined in concert with the data owners. Administrators should not be deciding who should have access to specific folders, documents, and databases. Each department should inform IT of its needs. However, once an administrator understands the requirements, she can implement them within the framework of the permissions available. File and folder permissions are composed of generic permission sets, as shown in Figure 5-1 and defined in Table 5-1. Each generic permission is actually a permission set. Several special permissions are included in the permission set. Each special permission can be assigned individually. Figure 5-2 displays the special permissions that make up Full Control. These permissions are defined in Table 5-2. A permission can be set to either Allow or Deny. Some permissions are only used for files, and others are only used on folders (as indicated in the table).

WARNING: Full Control Implies Delete Permission

If the Full Control permission is granted on a folder to a user or group, then that group may delete files within the folder, even if the user or group is not provided explicit access to the file or folder. This is also true if permissions are explicitly set on the file to deny that user or group access to the file. This property is called Child File Delete and was originally implemented to give the Windows NT Posix subsystem compliance with Posix 1.1. Posix is a Unix standard. At one time, compliance with the Posix standard was necessary to sell computers to branches of the federal government. The permission Child File Delete is part of the Posix standard.

Default Permissions

By default, Windows Server 2003 applies stronger access controls than Windows 2000. During installation, Windows 2000 applies granular permission sets to its system files. However, the group Everyone is granted Full Control at the root of the system drive. One concern at the time of its release was that changing permissions on the root drive during an upgrade might interfere with currently installed applications. Weak root file system permissions, however, weaken the security of the entire computer. When new applications are installed, they inherit the same weak permissions.

Windows Server 2003 applies stronger root file system permissions. The installation process sets access control lists on the root of the system volume that are more secure.

Administrators and SYSTEM
Full Control

CREATOR OWNER
Full Control on subfolders and files

Users
Create folders, append data on folders and subfolders

Users
Create files and subfolders only

However, the default permission set should be reviewed, and stronger permissions should be applied in many cases.

First, for some servers, it may be best to limit administrative access. An Exchange server or database server may be a good candidate for this treatment. To restrict administrative access, create a custom Windows group and add administrators who are authorized to administer the specific server. Grant this custom group Full Control and remove the local Administrators group.

The CREATOR OWNER group represents the account that created the file or folder. Any permissions granted to this group are assigned to the file or folder creator. If applications create folders and files, these permissions will be granted to the account that provides the security context for the application. That account may be an account assigned to the service or a user running the program. The CREATOR OWNER permission is often used to ensure that the appropriate permissions are applied. For example, when an application creates a file, the permissions applied to the file might be less than Full Control, thereby denying the person running the application ownership of the file. This is important because only the owner of a file can change its permissions to provide himself more access; therefore, if as the creator of the file, the user is not given ownership, he will be restricted to the access assigned. (Administrators and those assigned the user right Take Ownership can always take ownership and assign themselves any permissions on the file, but ordinary users do not have this right by default.) The specific requirements of applications and security policies of the organization may be different from those granted by the default permissions. Therefore, adjusting the default CREATOR OWNER permissions may be necessary. Default user permissions may also grant excessive permission on the files and folders they are authorized to create and should be reviewed to determine if they are appropriate. To determine the permission sets required for users, determine if users should be able to create files and folders on the server and determine where this may be necessary. It's not typically a requirement for the root of the drive. In many cases, a preferred arrangement is to provide users no access at the root and assign custom permissions to server folders where user access is required.

In all cases, permission inheritance should be reviewed. Unless a subfolder is marked to prevent inheritance, subfolders will inherit the permissions set on the root.

Instead of granting the Everyone group Full Control, creating a new file share grants the Everyone group Full Control. In addition to strengthening default access to shares, Windows Server 2003 does not include the anonymous SID in the Everyone group. Therefore, even if an anonymous connection can be made to the server, the anonymous user has no default permissions via the shares.

Permission Interpretation

Permission interpretation explains how permissions are evaluated. In its simplest form, the permissions that a user or group has on a file or folder are the combination of the permissions assigned. Realistically, however, the ability of a user to do something with a file or folder depends on a number of factors. Basically, the user requests some form of access, and the operating system walks the access control list (ACL) assigned to the file or folder looking for a match. Both the user's account SID and his group membership SIDs are reviewed. If access is explicitly denied, then the processing stops, and access is denied. If access is not explicitly granted, then it is denied. This is the same algorithm used to determine access since Windows NT. However, there is one difference between the old algorithm and Windows 2000/Server 2003: Inheritance may break the old NT rule that any Deny would automatically override any Allows and stop processing of the ACLs. To understand this difference, you must learn more about the NTFS disk structure and the location of ACLs.

WARNING: Deny Does Not Always Override Allow

A different inheritance mode for NTFS means that old rules about access control permission may not be valid. This is true because of a change in ACL location and therefore in the manner in which permissions are evaluated. It is possible that a Deny permission may not be interpreted before the required Allow permission is processed. This is because permissions applied directly on the object are applied first, and the inherited permissions are not considered if the directly applied permissions grant the required access. More information is in the section "Permission Inheritance," later in this chapter.

NTFS Disk Structure

Knowledge of file system architecture is useful should you need to forensically examine a disk, but more importantly, it can help you understand much about how NTFS works and the relationship between DACLs and performance. (For the basics of object security-object permissions, access tokens, groups, permission assignment, ACEs, and DACLs, refer to Chapter 3.) A significant change in the NTFS file structure was made for Windows 2000, and it was tweaked for performance in Windows Server 2003. This architectural change can affect security because administrators may still be approaching NTFS without understanding the change. Worse, trainers and experienced Windows administrators may communicate misinformation and perpetuate the problem. The change in the file structure itself is not a plus or a minus security-wise, unless you are forensically examining a disk, but it is important to understand. The primary change involves the location of the security descriptors.

Windows NT, Windows Server 2003, and Windows 2000 NTFS file volumes use a small database, the Master File Table (MFT), to assist in the location of files. MFT includes file and directory records that store and index filenames and other attributes, such as reparse points (mounts points for additional disks), link tracking information (to help in the location of files when locations are moved), and security descriptors. This is different than it was in Windows NT 4.0, where security descriptors (the attributes of files and folders that contain access control lists) were stored as attributes of the file objects they protected. Instead, a pointer in the file's attributes points back to the location in the MFT where the file's security descriptor can be found. Within the MFT, each file and folder has a record. The MFT metadata includes the $Secure record, which contains security descriptors for all MFT records. This does not mean that the MFT is bloated with double the data of earlier versions of NTFS. Instead, it only contains one copy of each unique security descriptor, which, of course, means that instead of one security descriptor for each file and folder on the entire disk, only a few security descriptors are stored. This arrangement also means that if a file has a large security descriptor (if many groups or users are given specific Allows or Denies), the security descriptor will not be fragmented and won't cause excessive disk activity when the file is accessed.

Permission Inheritance

The easiest way to think about permission inheritance is to construct a logical model that aligns with the file, folder, and subfolder hierarchal model of the file system. While security descriptors are actually stored in the MFT, they are applied to physical files and folders, so it's okay to speak of them as if they actually were properties of the files and folders, instead of talking about pointers to records. In the file system model, the root of the volume is divided into multiple volume-level folders, each of which can be divided up into subfolders, and on and on. Files can be located at the root and within every folder. The identification of a specific file is presented in a path that starts at the root and then may be followed by any number of subfolders until the file itself is named. In the NTFS file system, not only can each file and folder have files directly assigned permissions, but through permission inheritance, permissions assigned to a folder in the hierarchy can also be applied to every subfolder and file in the path. Inheritance can also be blocked or limited. If a new file is added to a folder, by default, it inherits its security descriptor from the parent folder. The security descriptor may include a combination of inherited and directly applied permissions.

Results of Inherited and Directly Applied Permissions

On any specific file, a combination of both directly applied and inherited permissions may be assigned. Effective permissions are the resultant set of these permissionsthe actual result of interpreting them. To determine what the effective permissions will be, use the following formula:

Windows Server 2003 also provides a report mechanism to evaluate permission combinations. To determine the effective permissions:

Impact of Copying and Moving NTFS Files and Folders

Copying and moving files or folders may change the permissions applied to them. The resulting permission set applied to either object is dependent on on the following:

The change is from and to folders on the same volume or to different volumes.

The object is copied or moved.

The object is marked to prevent inheritance.

Permissions on parent folders or the root are modified.

The inheritance mode of the objects is overridden.

The examples in this section can be reproduced on any Windows Server 2003 computer using the NTFS file system on which there are at least two volumes. The instructions listed were used to produce the results shown. Before proceeding, three top-level folderstest1, test2, and test3were created on drive C:\. Each folder inherits permissions from the root, as shown in Figure 5-6. In addition, two new Windows groups the Accountants group and the Sales groupwere created.

To prepare folders for testing, make the following changes:

Moving Files from Folder to Folder on the Same Volume

When existing files and folders are moved to a new location on the same volume, they do not immediately lose their current permissions.

Copying Files from Folder to Folder on the Same Volume

Moving Files from One Volume to Another

When files are moved between folders on the same volume, they retain their permissions until the parent permissions are changed. However, when moved between volumes, moved files inherit the permissions set in the new volume.

Overriding Blocked Inheritance

If copied or moved files have inheritance blocked, the files will not inherit permissions from the new folder. However, blocked inheritance can be overridden.

Copying DACLs with Xcopy

If the xcopy command and its /O switch are used for copying, existing permissions are retained, and permissions are inherited from the new location.

xcopy /O C:\test1 E:\test1

Permission Summary

Be sure to determine if moving and copying files will have the correct effect on file access. As demonstrated previously, permissions may change. Prevent unexpected improper access control settings by keeping in mind that the permissions that are applied to moved or copied files and folders may change depending on these factors:

Where they were created

Whether they were moved or copied to a new location

Whether xcopy or Windows Explorer was used

Whether the new location was on the same volume or a different one

Whether they had their own security descriptor or an inherited one

Whether inheritance was blocked

What the inheritance settings were on the folder moved or copied to

NTFS Attributes and Performance Versus Security

Using a more complex file system and adding security may impact performance. The benefits of granular security must be weighed against any performance losses. Before making any configuration choices intended to improve performance, the new features and the security implications of making changes should be evaluated.

NTFS Performance ImprovementLocation of File Descriptors

Each file and directory contains a number of attributes. The file property $Standard_Information contains the regular file attributes, such as Read-Only, Hidden, System, Archive, Timestamps, and a pointer to the security descriptor in the $Secure record in the MFT. Locating the security descriptor in the MFT does aid file system performance and to some degree refute the argument that we should not add security information because it will hinder performance. (When discussing file system security, Windows NT 4.0 users often heard the argument that many large ACLs would reduce performance because the ACLs might become fragmented, or because when ACLs are changed in Windows NT 4.0, all subfolders and files would inherit the new ACL. Because the assignment of ACLs is now handled using pointers to the new ACL, and because all ACLs exist only in the MFT, the old argument is no longer valid.)

The file system can quickly figure out whether a new security descriptor is unique and must be stored, or whether it already exists and just needs to be pointed to. To do so, the file system stores a hash of each security descriptor in the MFT. When a new ACL is created on a file or folder, the new security descriptor is hashed by the system and then compared to those that already exist in the MFT. If no match is found, then the security descriptor must be stored; if a match is found, then it does not need to be stored. As you may already know, many hash algorithms exist for which it is statistically infeasible that two different pieces of data can produce the same result when hashed. This is why a match with an existing hash means no new security descriptor needs to be stored.

Timestamp Performance Issues

Another potential performance issue concerns timestamps. Timestamps stored in file attributes indicate record creation, attribute modification, and data or index modification in addition to the time of last access. Updating timestamps does require disk activity. On a large disk with a large number of files that are frequently accessed, this could be significant enough that reducing the timestamp activity might provide some small gain in performance. However, be wary of advice that calls for eliminating the "update to last access" timestamp. The last access time stamp, of course, indicates when a file was last changed and can be useful forensics information, as a simple indication of possible tampering, or as proof that a file has not been affected by an attempted attack.

Administrators may eliminate last access update timestamps in an attempt to improve performance, but they should not. Accurate timestamps are necessary to obtain accurate audit and forensic information and to comply with policies that require it. You can determine if last access update has been modified by inspecting the REG_DWORD value NtfsDisableLastAccessUpdate at HKEY_LOCAL_MACHINE\SYSTEM\ Current Control Set\Control\filesystem. Protect this value from change by using registry permissions, and turn on auditing to capture any change that might be performed by administrators.