Difference between revisions of "Access Control List"
(→History) |
(→Technical Details) |
||
| (4 intermediate revisions by the same user not shown) | |||
| Line 23: | Line 23: | ||
The idea gained traction and evolved through systems like PRIMOS in the 1980s and later became standardized in various forms, including POSIX ACLs and NFSv4 ACLs. Today, ACLs are ubiquitous in operating systems, firewalls, and network devices, offering fine-grained control over who can do what with digital resources. | The idea gained traction and evolved through systems like PRIMOS in the 1980s and later became standardized in various forms, including POSIX ACLs and NFSv4 ACLs. Today, ACLs are ubiquitous in operating systems, firewalls, and network devices, offering fine-grained control over who can do what with digital resources. | ||
| − | In Windows, Access Control Lists (ACLs) are embedded in the security descriptors of securable objects—like files, folders, registry keys, and even Active Directory objects. You can view and manage them through both graphical tools and command-line utilities. | + | In Windows, Access Control Lists (ACLs) are embedded in the security descriptors of securable objects—like files, folders, registry keys, and even Active Directory objects. You can view and manage them through both graphical tools and command-line utilities. ACLs are stored in the Discretionary Access Control List (DACL) and optionally a System Access Control List (SACL) for mandatory control elements within the object’s security descriptor. You can programmatically access or modify them using Windows API functions like GetSecurityInfo, SetEntriesInAcl, and SetSecurityInfo |
===The Deep Roots of Access Control=== | ===The Deep Roots of Access Control=== | ||
| Line 33: | Line 33: | ||
Locke, Hobbes, and Delegated Sovereignty: In Enlightenment political philosophy, Locke’s emphasis on consent and Hobbes’s insistence on a sovereign’s absolute authority both wrestle with ideas of who gets access to power and under what constraints—just like a system administrator. | Locke, Hobbes, and Delegated Sovereignty: In Enlightenment political philosophy, Locke’s emphasis on consent and Hobbes’s insistence on a sovereign’s absolute authority both wrestle with ideas of who gets access to power and under what constraints—just like a system administrator. | ||
| + | |||
| + | ==Technical Details== | ||
| + | Access control can be discretionary or mandatory.<ref>DoD, ''Trusted Computer System Evaluation'' DoD 5200-28 STD 1985-12 </ref> | ||
| + | * See the wiki on [[Mandatory Access Control]]. | ||
===ACLs vs. Role-Based Access Control (RBAC)=== | ===ACLs vs. Role-Based Access Control (RBAC)=== | ||
Latest revision as of 09:27, 3 July 2025
Contents
Definition
An Access Control List (ACL) is a data structure used in computer systems to define which users or system processes are allowed to access specific resources, and what operations they’re
Context
Each entry in an ACL typically includes:
- A subject (like a user or group)
- A set of permissions (e.g., read-only, full control)
For example, an ACL on a file might say:
- Alice: read, write
- Bob: read
ACLs are used in:
- Operating systems (e.g., Windows, Linux) to manage file and folder permissions
- Network devices (like routers and firewalls) to filter traffic based on IP addresses, ports, or protocols
- Databases to control access to tables, views, or even individual fields
- They’re foundational to discretionary access control (DAC) models
History
The concept of an access list for computer resources—what we now call an Access Control List (ACL)—originated with the Multics operating system in the mid-1960s. Multics (Multiplexed Information and Computing Service) was a pioneering time-sharing system that introduced many foundational ideas in computer security and operating system design.
ACLs in Multics were designed to specify which users or processes could access specific system resources, and what operations (like read, write, or execute) they were allowed to perform. This was a major step forward from earlier, more monolithic security models, and it laid the groundwork for modern discretionary access control systems.
The idea gained traction and evolved through systems like PRIMOS in the 1980s and later became standardized in various forms, including POSIX ACLs and NFSv4 ACLs. Today, ACLs are ubiquitous in operating systems, firewalls, and network devices, offering fine-grained control over who can do what with digital resources.
In Windows, Access Control Lists (ACLs) are embedded in the security descriptors of securable objects—like files, folders, registry keys, and even Active Directory objects. You can view and manage them through both graphical tools and command-line utilities. ACLs are stored in the Discretionary Access Control List (DACL) and optionally a System Access Control List (SACL) for mandatory control elements within the object’s security descriptor. You can programmatically access or modify them using Windows API functions like GetSecurityInfo, SetEntriesInAcl, and SetSecurityInfo
The Deep Roots of Access Control
The concept of controlling who can access what—embedded in modern ACLs—has long parallels in governance and law:
Roman and Medieval Authority: Roman systems of imperium granted specific powers to consuls or governors, much like ACLs grant specific rights (read/write/execute) to users. In medieval times, feudal contracts specified land rights and obligations—early role-based delegation, if you will.
Canon Law and Mandates: Religious institutions often operated under strict, recorded permissions for who could perform rites or hold office. These were, in essence, access lists guarded by bureaucratic keys.
Locke, Hobbes, and Delegated Sovereignty: In Enlightenment political philosophy, Locke’s emphasis on consent and Hobbes’s insistence on a sovereign’s absolute authority both wrestle with ideas of who gets access to power and under what constraints—just like a system administrator.
Technical Details
Access control can be discretionary or mandatory.[1]
- See the wiki on Mandatory Access Control.
ACLs vs. Role-Based Access Control (RBAC)
ACLs define permissions per object: “Tom can read file.txt, but not write.”
RBAC defines permissions per role: “All ‘engineers’ can read/write project/.”
RBAC reflects organizational hierarchies and job functions, and it scales better in large systems—but it draws from the administrative abstraction seen in bureaucratic states and military structures. It’s governance by groups, not by name.
If we zoom out, both models reflect competing philosophies: ACLs favor individual Identifiers, while RBAC leans on institutional role Identifiers.
References
- ↑ DoD, Trusted Computer System Evaluation DoD 5200-28 STD 1985-12
