In order for a user to perform an action on a secured entity like a file or directory, the user must have permission to do so. In this case, a permission is an access control entry that links the action to be performed to the security identifier of the user account attempting the
operation. If the link exists, the operating system executes the action; otherwise, it will deny access and display an error message.
permission
An Access Control Entry in an object’s Discretionary Access Control List.
Windows maintains security for various types of objects including (but not limited to) directories, files, printers, processes, and network shares. Each object exposes services that the object allows to be performed upon it, for example: open, close, read, write, delete, start, stop, print, and so on.
objects
Data structures in a computer environment, such as files, directories, printers, shares, and so forth.
The security information for an object is contained in the object’s Security Descriptor. The security descriptor has four parts: owner, group, Discretionary Access Control List
(DACL), and System Access Control List (SACL). Windows uses these parts of the security descriptor for the following purposes:
Security Descriptor
Information stored with each object that specifies the owner and contains the Access Control List.
Discretionary Access Control List (DACL)
The Access Control List that is used to allow or deny access to an object. System Access Control List (SACL)
An Access Control List used to determine how to audit objects.
Owner This part contains the SID of the user account that has ownership of the object. The object’s owner may always change the settings in the DACL (the permissions) of the object, irrespective of whether or not the owner has permission to access the file.
owner
The user account that created an object or was otherwise assigned ownership. The owner of an object has the right to change its permissions irrespective of user account’s permissions. Group This part is used by the POSIX subsystem of Windows. Files and directories in Unix operating systems can belong to a group as well as to an individual user account. This part contains the SID of the group of this object for the purposes of POSIX compatibility. Windows does not use this field for any other purpose. Don’t be confused by the name: Windows security groups cannot be owners of a resource. Group security and permissions are managed through the DACL, not through this field.
Discretionary Access Control List The DACL contains a list of user accounts and group accounts that have permission to access the object’s services. The DACL has as many access control entries as there are user or group accounts that have been specifically given access to the object.
System Access Control List The SACL also contains Access Control Entries (ACEs), but these ACEs are used for auditing rather than for permitting or denying access to the object’s services. The SACL has as many ACEs as there are user or group accounts that are
specifically being audited. Access Control Entry (ACE)
An entry in an Access Control List that joins a security identifier to a type of allowed or denied access.
Access to a resource will be allowed if an access token contains any SID that matches a permission in the DACL that corresponds to the type of access requested. For example, if an individual account is allowed Read access, and the user account is a member of a group account that is allowed Write access, then the access token for that logged-on user will contain both SIDs and the LSA will allow Read and Write access to the object because the DACL contains an entry that matches each type of access. Deny ACEs still override any accumulation of permission.
For example, if user mstrebe wants to access a file called address.txt, then the system
(actually a component called the Security Reference Monitor) will compare the access token of his running the WINWORD.EXE program to the DACL associated with address.txt. If address.txt has any SID in common with the access token for WINWORD.EXE that allows Read access, then he can open the file, otherwise access is denied.
A special type of ACE, called a deny ACE, indicates that all access to the object will be denied to the account identified by the SID. A deny ACE overrides all other ACEs. Windows implements the No Access permission using the deny ACE.
deny ACE
An Access Control Entry that specifically denies permissions, in order to override other permissions that might allow access to the account.
The access control entries in the SACL are formed the same way as the ACEs in the DACL (they are composed of a SID and an access mask), but the access mask, in this case, identifies those services of the object for which the account will be audited.
Not every object has a security descriptor. The FAT file system, for example, does not record security information, so file and directory objects stored on a FAT volume lack owners, DACLs, and SACLs. When a security descriptor is missing, any user account may access any
of the object’s services. This is not the same as when an object has an empty DACL. In that case, no account may access the object. When there is no SACL for an object, that object may not be audited. An existing but empty SACL indicates that an object can be but is not
currently being audited. Rights versus Permissions
There are activities that do not apply to any specific object, but instead apply to a group of objects or to the operating system as a whole. Shutting down the operating system, for example, affects every object in the system. Operations of this nature require the user to have user rights to perform the operation.
user rights
Actions that a user account can perform that apply to many or all objects in a system. Earlier in this chapter, I mentioned the Local Security Authority includes a Locally Unique Identifier when it creates an access token. The LUID describes which of the user rights that particular user account has. The Local Security Authority creates the LUID from security information in the Security Accounts Manager database. The SAM database matches users with rights. The LUID is a combination of the rights of that specific user account along with the rights of all the groups of which that account is a member.
Rights take precedence over permissions. That’s why the Administrator account can take ownership of a file to which the owner of the file has set the No Access to Everyone permission; the Administrator has the Take Ownership of Files or Other Objects right. The Windows operating system checks the user rights first, and then (if there is no user right specifically allowing the operation) the operating system checks the ACEs stored in the DACL against the SIDs in the access token.
User accounts have the right to read or write to an object the user account owns even in the case of a No Access permission. The owner may also change the permissions of an object irrespective of the object’s existing permissions.
No Access permission See deny ACE.