The access control lists ACL in the default security descriptor for a file or directory are inherited from its parent directory. Note that a default security descriptor is assigned only when a file or directory is newly created, and not when it is renamed or moved. The table in File Access Rights Constants lists the access rights that are specific to files and directories. The following are the generic access rights for files and directories. Windows compares the requested access rights and the information in the thread's access token with the information in the file or directory object's security descriptor.
If the comparison does not prohibit all of the requested access rights from being granted, a handle to the object is returned to the thread and the access rights are granted. For more information about this process, see Interaction between Threads and Securable Objects.
By default, authorization for access to a file or directory is controlled strictly by the ACLs in the security descriptor associated with that file or directory. In particular, the security descriptor of a parent directory is not used to control access to any child file or directory.
This is not recommended in the general case, as many programs do not correctly handle directory traversal errors. The Windows security model provides a way for a child directory to inherit, or to be prevented from inheriting, one or more of the ACEs in the parent directory's security descriptor.
Each ACE contains information that determines how it can be inherited, and whether it will have an effect on the inheriting directory object. For example, some inherited ACEs control access to the inherited directory object, and these are called effective ACEs. This automatic inheritance, along with the inheritance information in each ACE, determines how security restrictions are passed down the directory hierarchy.
Another means of managing access to storage objects is encryption. Deny log on through Remote Desktop Services. Enable computer and user accounts to be trusted for delegation. Force shutdown from a remote system. Impersonate a client after authentication.
Increase a process working set. Increase scheduling priority. Load and unload device drivers. Manage auditing and security log. Modify firmware environment values. Obtain an impersonation token for another user in the same session. Perform volume maintenance tasks. Profile system performance. Remove computer from docking station. Replace a process level token. Restore files and directories.
Synchronize directory service data. Take ownership of files or other objects. Thus, ordering of ACEs is important. It is worthwhile now to look at what a realistic security descriptor looks like. Here's a security descriptor for the root of the Windows Server system drive note that cacls is a legacy command-line routine for investigating and setting ACLs and is being replaced by icacls.
Based upon what we know about security descriptors, you can see from the leading "D:" that no ownership or group membership is claimed and that the descriptor is a DACL. The hex representation and associated bit values are shown in Figure 7.
The system uses a single bitmap representation of ACE rights for all objects. Not all bits are meaningful for various objects. Only rights that are appropriate for an object are applied.
Standard rights are those rights that are common to all securable objects. Generic rights are convenient shorthand for specifying rights of similar intent for various objects.
The specification of generic rights is mapped into the appropriate set of specific rights. The available rights for various objects are listed in Figure 8. There are a number of largely equivalent rights mappings that are used rather indiscriminately.
For the file system, File All FA is the appropriate full control declaration. Key All KA is the appropriate full control declaration for the registry. Generic declarations are frequently used in place of the more appropriate declarations but are mapped to the appropriate file system or registry key declarations, as appropriate.
SDDL expressions frequently mix these terms, thus you need to be aware of the equivalences. Many objects can be assigned rights. In addition to files and directories, we have registry keys, processes, desktops, and so forth.
For the full list, see Figures A through J. Since we will be discussing permissions on the file system and registry, the specific rights for these objects are provided in Figures 9 and As was already stated, the integrity labels, if present, are stored in the object's SACL.
Objects implicitly have medium integrity, so if there is no integrity label, the object has medium integrity. Similarly, if there is no integrity label on a security token, it also has medium integrity. The low-integrity label is used to label Low Rights processes, such as LowRights Internet Explorer and related untrusted objects.
The "high" and "system" levels are used to help isolate those objects from medium and low processes and objects. The integrity labels are shown in Figure They are not used when securing the file system or registry. The SID string notation for common accounts is used wherever possible to make the system more readable. This creates a problem if a user is a member of a group and creates a large number of objects.
This allows mitigation of this security issue. This is a protected DACL with the auto-inherit flag for a modern file systems set. The protected flag means that inheritable parent grants won't be inherited; the DACL is protected from inheritance from the object's parent.
In this case there is no parent, as it is the root. The built-in administrator and system are granted inheritable File All over both files due to the object inherit and directories due to the container inherit, or CI.
The grant to the built-in user is far more interesting. This is the same as you saw when you explored these permissions with the ACL graphical interface of Windows Explorer. Starting with Windows Server and Windows Vista, components declare their needed security settings in their manifests, which are signed by a Microsoft code signing root.
The manifest specifies the ACLs and other permissions associated with the file. Thus, when a component is installed, it carries with it the appropriate security settings.
WRP relies upon a new system-level entity, Trusted Installer, to own and manage system files and folders. A good facility to allow normal users to perform installations of authorized components was added in Windows Vista. The Power User group still exists, but the component manifests have been scanned, and all detected instances of grants to PU have been deleted.
Let's look at a system directory to see the new permissions. This is also another good exercise in SDDL reading:. Using TI as shorthand, we find the following:. Since the admin has the take ownership privilege, he can still assert WriteOwnership and take control anyway. Administrator and system are a security equivalent. The control of files by Trusted Installer is not expressed in the declaration on the system root directory but in the separate declarations of the Windows components.
Now that you have some idea of how file system ACLs work and how to read them, let's look at setting them. If you are installing an application, you should install this to the default Program Files location.
If you install an application to some other location or grant the user the ability to choose his preferred location for an application, you have a problem: the default ACLs for other drives and for non-system and non-application areas of the system drive are not secure enough. The simplest and safest choice for installing an application is to duplicate the security settings on the Program Files folder.
If you choose not to do this, set the DACL so that non-administrators cannot change DACLs or ownership of executables and cannot write, append, or delete files in directories containing executables.
The basic rule if you are setting DACLs is that you do not want administrators or other users executing code that was written by a user.
0コメント