Skip to main content
Engineering LibreTexts

3.2: Access Control - ACL

  • Page ID
    45980
  • Access Control Lists

    In any access-control model, the entities that can perform actions on the system are called subjects, and the entities representing resources to which access may need to be controlled are called objects. Subjects and objects should both be considered as software entities, rather than as human users: any human users can only have an effect on the system via the software entities that they control.

    Although some systems equate subjects with user IDs, so that all processes started by a user by default have the same authority, this level of control is not fine-grained enough to satisfy the principle of least privilege, and arguably is responsible for the prevalence of malware in such systems (see computer insecurity).

    In some models, for example the object-capability model, any software entity can potentially act as both subject and object.

    As of 2014, access-control models tend to fall into one of two classes: those based on capabilities and those based on access control lists (ACLs).

    • In a capability-based model, holding an unforge-able reference or capability to an object, that provides access to the object (roughly analogous to how possession of one's house key grants one access to one's house); access is conveyed to another party by transmitting such a capability over a secure channel.
    • In an ACL-based model, a subject's access to an object depends on whether the subject's identity appears on a list associated with the object (roughly analogous to how a bouncer at a private party would check an ID to see if a name appears on the guest list); access is conveyed by editing the list. (Different ACL systems have a variety of different conventions regarding who or what is responsible for editing the list and how it is edited.)

    Both capability-based and ACL-based models have mechanisms to allow access rights to be granted to all members of a group of subjects (often the group is itself modeled as a subject).

    Filesystem ACLs

    A filesystem ACL is a data structure (usually a table) containing entries that specify individual user or group rights to specific system objects such as executable programs, running processes, or files. These entries are known as access-control entries (ACEs) in the Microsoft Windows NT, OpenVMS, and Unix-like operating systems such as Linux, macOS, and Solaris. Each accessible object contains an identifier to its ACL. The privileges or permissions determine specific access rights, such as whether a user can read from, write to, or execute an object. In some implementations, an ACE can control whether or not a user, or group of users, may alter the ACL on an object.

    Networking ACLs

    On some types of proprietary computer-hardware (in particular routers and switches), an access-control list provides rules that are applied to port numbers or IP addresses that are available on a host or other layer 3, each with a list of hosts and/or networks permitted to use the service. Although it is additionally possible to configure access-control lists based on network domain names, this is a questionable idea because individual TCP, UDP, and ICMP headers do not contain domain names. Consequently, the device enforcing the access-control list must separately resolve names to numeric addresses. This presents an additional attack surface for an attacker who is seeking to compromise security of the system which the access-control list is protecting. Both individual servers as well as routers can have network ACLs. Access-control lists can generally be configured to control both inbound and outbound traffic, and in this context they are similar to firewalls. 

    Adapted from:
    "Computer access control" by Multiple ContributorsWikipedia is licensed under CC BY-SA 3.0
    "Access-control list" by Multiple ContributorsWikipedia is licensed under CC BY-SA 3.0

    • Was this article helpful?