ACL (Access Control List)
This page was last modified on 22 June 2016, at 15:38.
An access control list or ACL, with respect to a computer file system, is a list of permissions attached to an object. An ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed on given objects. Each entry in a typical ACL specifies a subject and an operation. For instance, if a file object has an ACL that contains (Alice: read,write; Bob: read), this would give Alice permission to read and write the file and Bob to only read it.
Every user and computer has a specific role and purpose in an organization. To accomplish their goals, each user and computer must be able to access certain resources and perform specific tasks. However, allowing users and computers unlimited access to system and network resources and functionality can compromise an organization’s security and stability. The access control infrastructure of Windows XP Professional functions to balance the resource access and system security needs of an organization. For example, Alice works in Accounting and needs to be able to view—but not create or modify—certain Personnel department files that are off-limits to other users in the organization. The Personnel department, which controls these files, uses access control to define which users can have Read-only access to Personnel files, which users can have Write and Modify access, and which users have no access to the Personnel share. Alice is given Read-only access to the Personnel files. Similarly, IT determines that prohibiting users such as Alice from making significant changes to their systems can reduce costs and improve security and supportability. IT makes Alice and other users members of the Users group, thus limiting their ability to install applications and reconfigure their operating system environments. In this way, Alice has the access to resources that she needs, the security of the organization is enforced, and the stability of the network is maintained.
Discretionary access to securable objects
The user who owns an object has ultimate control over who has permission to use it and in what way. An object’s owner can give permission for different kinds of access to particular users or groups of users. For example, the owner of a file object can give Read and Write permission to all members of one group while denying Write access to members of another group. In Windows XP Professional, owners can Allow or Deny other users access to individual properties of certain types of objects as well as to the entire object. The properties that can be delegated include permissions that Allow or Deny other users access to the object.
Inheritance of permissions
You can control permissions for new objects created in a container object by setting inheritable permissions on the container. The permissions that you set on a container are inherited by existing objects in the container, as well as by newly created objects. For example, the permissions that are set on an NTFS file system folder are inherited by new subfolders and files created within the folder.
Auditing of system events
You can use the auditing feature to detect attempts to circumvent protections on resources or to create an audit trail of administrative actions on the system. For example, you can audit failed attempts to open a file. You can also set security policy so that failed logon attempts are recorded in the security event log. If another administrator changes the auditing policy so that failed logon attempts are no longer audited, the log can record this event as well. In an Active Directory environment, you can use Group Policy to centrally control who is allowed to manage security logs on computers joined to a domain.
Rights and Permissions
Access control involves the configuration of rights and permissions, which apply to both the objects on the local computer or network and the potential users (including individuals, computers, and services) of those objects.
A right is authorization to perform an operation. From an administrator’s point of view, there are two types of rights: privileges and logon rights. In Windows XP Professional, only one user right is inherent—the right to allow or deny access to resources that you own. All other user rights must be granted, which means that they can also be withdrawn.
A permission is authorization to perform an operation on a specific object, such as opening a file. Permissions are granted by owners. If you own an object, you can grant any user or security group permission to do whatever you are authorized to do with it.
When permission to perform an operation is not explicitly granted, it is implicitly denied. For example, if Alice allows the Marketing group, and only the Marketing group, permission to read her file, users who are not members of the Marketing group are implicitly denied access. The operating system will not allow users who are not members of the Marketing group to read the file.
Permissions can also be explicitly denied. For example, Alice might not want Bob to be able to read her file, even though he is a member of the Marketing group. She can exclude Bob by explicitly denying him permission to read the file. In fact, this is exactly how explicit denials are best used—to exclude a subset (such as Bob) from a larger group (such as Marketing) that has been given permission to do something.
Each permission that an object’s owner grants to a particular user or group is stored as part of an ACE in a DACL that is part of the object’s security descriptor.
Every application that a user starts runs in the security context of that user. When a user logs on, an access token is created. The access token contains key security-related information, including the user’s SID, the SIDs of the groups to which the user belongs, and other information about the user’s security context. This access token is then attached to every process that the user runs during that logon session. An application runs as a process with threads of execution. When an application performs an operation on a user’s behalf, one of the threads performs the operation. For example, when Alice opens a Word document, Microsoft Word, and not Alice, actually opens the file. More precisely, one of the threads of execution performs the operation. For a thread to gain access to an object such as a file, it must identify itself to the operating system’s security subsystem. Threads and applications do not have a security identity, so they must borrow one from a security principal, such as Alice. When Alice starts an application, it runs as a process within her logon session. When one of the application’s threads needs to open a file, the thread identifies itself as Alice’s agent by presenting her access token. Alice is therefore ultimately responsible for anything that the thread does to the file or system on her behalf.