Access-control list

Last updated April 17, 2024

In computer security, an access-control list (ACL) is a list of permissions^{[lower-alpha 1]} associated with a system resource (object or facility). An ACL specifies which users or system processes are granted access to resources, as well as what operations are allowed on given resources.^[1] 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 give Bob permission only to read it.
If the RACF profile CONSOLE CLASS(TSOAUTH) has an ACL that contains (ALICE:READ), this would give ALICE permission to use the TSO CONSOLE command.

Implementations

Many kinds of operating systems implement ACLs or have a historical implementation; the first implementation of ACLs was in the filesystem of Multics in 1965.^[2]^[3]

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 programs, processes, or files. These entries are known as access-control entries (ACEs) in the Microsoft Windows NT,^[4] 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.

One of the first operating systems to provide filesystem ACLs was Multics. PRIMOS featured ACLs at least as early as 1984.^[5]

In the 1990s the ACL and RBAC models were extensively tested^{[ by whom? ]} and used to administer file permissions.

POSIX ACL

POSIX 1003.1e/1003.2c working group made an effort to standardize ACLs, resulting in what is now known as "POSIX.1e ACL" or simply "POSIX ACL".^[6] The POSIX.1e/POSIX.2c drafts were withdrawn in 1997 due to participants losing interest for funding the project and turning to more powerful alternatives such as NFSv4 ACL.^[7]As of December 2019^[update], no live sources of the draft could be found on the Internet, but it can still be found in the Internet Archive.^[8]

Most of the Unix and Unix-like operating systems (e.g. Linux since 2.5.46 or November 2002,^[9] FreeBSD, or Solaris) support POSIX.1e ACLs (not necessarily draft 17). ACLs are usually stored in the extended attributes of a file on these systems.

NFSv4 ACL

NFSv4 ACLs are much more powerful than POSIX draft ACLs. Unlike draft POSIX ACLs, NFSv4 ACLs are defined by an actually published standard, as part of the Network File System.

NFSv4 ACLs are supported by many Unix and Unix-like operating systems. Examples include AIX, FreeBSD,^[10] Mac OS X beginning with version 10.4 ("Tiger"), or Solaris with ZFS filesystem,^[11] support NFSv4 ACLs, which are part of the NFSv4 standard. There are two experimental implementations of NFSv4 ACLs for Linux: NFSv4 ACLs support for Ext3 filesystem^[12] and the more recent Richacls, which brings NFSv4 ACLs support for Ext4 filesystem.^[13] As with POSIX ACLs, NFSv4 ACLs are usually stored as extended attributes on Unix-like systems.

NFSv4 ACLs are organized nearly identically to the Windows NT ACLs used in NTFS.^[14] NFSv4.1 ACLs are a superset of both NT ACLs and POSIX draft ACLs.^[15] Samba supports saving the NT ACLs of SMB-shared files in many ways, one of which is as NFSv4-encoded ACLs.^[16]

Active Directory ACLs

Microsoft's Active Directory service implements an LDAP server that store and disseminate configuration information about users and computers in a domain.^[17] Active Directory extends the LDAP specification by adding the same type of access-control list mechanism as Windows NT uses for the NTFS filesystem. Windows 2000 then extended the syntax for access-control entries such that they could not only grant or deny access to entire LDAP objects, but also to individual attributes within these objects.^[18]

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 and 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. Like firewalls, ACLs could be subject to security regulations and standards such as PCI DSS.

SQL implementations

ACL algorithms have been ported to SQL and to relational database systems. Many "modern" (2000s and 2010s) SQL-based systems, like enterprise resource planning and content management systems, have used ACL models in their administration modules.

Comparing with RBAC

The main alternative to the ACL model is the role-based access-control (RBAC) model. A "minimal RBAC model", RBACm, can be compared with an ACL mechanism, ACLg, where only groups are permitted as entries in the ACL. Barkley (1997)^[19] showed that RBACm and ACLg are equivalent.

In modern SQL implementations, ACLs also manage groups and inheritance in a hierarchy of groups. So "modern ACLs" can express all that RBAC express and are notably powerful (compared to "old ACLs") in their ability to express access-control policy in terms of the way in which administrators view organizations.

For data interchange, and for "high-level comparisons", ACL data can be translated to XACML.^[20]

Notes

↑ E.g., File-system permissions, permission to perform specific action.

Related Research Articles

Cygwin is a Unix-like environment and command-line interface for Microsoft Windows.

New Technology File System (NTFS) is a proprietary journaling file system developed by Microsoft. Starting with Windows NT 3.1, it is the default file system of the Windows NT family. It superseded File Allocation Table (FAT) as the preferred filesystem on Windows and is supported in Linux and BSD as well. NTFS reading and writing support is provided using a free and open-source kernel implementation known as NTFS3 in Linux and the NTFS-3G driver in BSD. By using the convert command, Windows can convert FAT32/16/12 into NTFS without the need to rewrite all files. NTFS uses several files typically hidden from the user to store metadata about other files stored on the drive which can help improve speed and performance when reading data. Unlike FAT and High Performance File System (HPFS), NTFS supports access control lists (ACLs), filesystem encryption, transparent compression, sparse files and file system journaling. NTFS also supports shadow copy to allow backups of a system while it is running, but the functionality of the shadow copies varies between different versions of Windows.

Security-Enhanced Linux (SELinux) is a Linux kernel security module that provides a mechanism for supporting access control security policies, including mandatory access controls (MAC).

In computing, a system call is the programmatic way in which a computer program requests a service from the operating system on which it is executed. This may include hardware-related services, creation and execution of new processes, and communication with integral kernel services such as process scheduling. System calls provide an essential interface between a process and the operating system.

In computing, a symbolic link is a file whose purpose is to point to a file or directory by specifying a path thereto.

The Unix file system (UFS) is a family of file systems supported by many Unix and Unix-like operating systems. It is a distant descendant of the original filesystem used by Version 7 Unix.

Capability-based security is a concept in the design of secure computing systems, one of the existing security models. A capability is a communicable, unforgeable token of authority. It refers to a value that references an object along with an associated set of access rights. A user program on a capability-based operating system must use a capability to access an object. Capability-based security refers to the principle of designing user programs such that they directly share capabilities with each other according to the principle of least privilege, and to the operating system infrastructure necessary to make such transactions efficient and secure. Capability-based security is to be contrasted with an approach that uses traditional UNIX permissions and Access Control Lists.

pax is an archiving utility available for various operating systems and defined since 1995. Rather than sort out the incompatible options that have crept up between tar and cpio, along with their implementations across various versions of Unix, the IEEE designed new archive utility pax that could support various archive formats with useful options from both archivers. The pax command is available on Unix and Unix-like operating systems and on IBM i, and Microsoft Windows NT until Windows 2000.

In computer security, mandatory access control (MAC) refers to a type of access control by which the operating system or database constrains the ability of a subject or initiator to access or generally perform some sort of operation on an object or target. In the case of operating systems, a subject is usually a process or thread; objects are constructs such as files, directories, TCP/UDP ports, shared memory segments, IO devices, etc. Subjects and objects each have a set of security attributes. Whenever a subject attempts to access an object, an authorization rule enforced by the operating system kernel examines these security attributes and decides whether the access can take place. Any operation by any subject on any object is tested against the set of authorization rules to determine if the operation is allowed. A database management system, in its access control mechanism, can also apply mandatory access control; in this case, the objects are tables, views, procedures, etc.

Filesystem in Userspace (FUSE) is a software interface for Unix and Unix-like computer operating systems that lets non-privileged users create their own file systems without editing kernel code. This is achieved by running file system code in user space while the FUSE module provides only a bridge to the actual kernel interfaces.

Most file systems include attributes of files and directories that control the ability of users to read, change, navigate, and execute the contents of the file system. In some cases, menu options or functions may be made visible or hidden depending on a user's permission level; this kind of user interface is referred to as permission-driven.

Unix-like operating systems identify a user by a value called a user identifier, often abbreviated to user ID or UID. The UID, along with the group identifier (GID) and other access control criteria, is used to determine which system resources a user can access. The password file maps textual user names to UIDs. UIDs are stored in the inodes of the Unix file system, running processes, tar archives, and the now-obsolete Network Information Service. In POSIX-compliant environments, the shell command id gives the current user's UID, as well as more information such as the user name, primary user group and group identifier (GID).

File attributes are a type of meta-data that describe and may modify how files and/or directories in a filesystem behave. Typical file attributes may, for example, indicate or specify whether a file is visible, modifiable, compressed, or encrypted. The availability of most file attributes depends on support by the underlying filesystem where attribute data must be stored along with other control structures. Each attribute can have one of two states: set and cleared. Attributes are considered distinct from other metadata, such as dates and times, filename extensions or file system permissions. In addition to files, folders, volumes and other file system objects may have attributes.

Extended file attributes are file system features that enable users to associate computer files with metadata not interpreted by the filesystem, whereas regular attributes have a purpose strictly defined by the filesystem. Unlike forks, which can usually be as large as the maximum file size, extended attributes are usually limited in size to a value significantly smaller than the maximum file size. Typical uses include storing the author of a document, the character encoding of a plain-text document, or a checksum, cryptographic hash or digital certificate, and discretionary access control information.

The following tables compare general and technical information for a number of file systems.

In Unix-like operating systems, a device file or device node or special file is an interface to a device driver that appears in a file system as if it were an ordinary file. There are also special files in DOS, OS/2, and Windows. These special files allow an application program to interact with a device by using its device driver via standard input/output system calls. Using standard system calls simplifies many programming tasks, and leads to consistent user-space I/O mechanisms regardless of device features and functions.

Richacls is a Linux implementation of the NFSv4 ACLs which has been extended by file masks to more easily fit the proprietary POSIX draft file permission model. Nowadays, they offer the most complex permission model for ext4 file system in Linux. They are even more complex than POSIX draft ACLs, which means it is not possible to convert back from Richacls to Linux' implementation of the POSIX draft ACLs without losing information. One of the most important advantages is that they distinguish between write and append permission, between delete and delete child permissions, and make ACL management access discretionary. They are also designed to support Windows interoperability.

The NetBSD rump kernel is the first implementation of the "anykernel" concept where drivers either can be compiled into or run in the monolithic kernel or in user space on top of a light-weight kernel. The NetBSD drivers can be used on top of the rump kernel on a wide range of POSIX operating systems, such as the Hurd, Linux, NetBSD, DragonFly BSD, Solaris kernels and even Cygwin, along with the file system utilities built with the rump libraries. The rump kernels can also run without POSIX directly on top of the Xen hypervisor, an L4 microkernel using the Genode OS Framework or even on "OS-less" bare metal.

In computer security, general access control includes identification, authorization, authentication, access approval, and audit. A more narrow definition of access control would cover only access approval, whereby the system makes a decision to grant or reject an access request from an already authenticated subject, based on what the subject is authorized to access. Authentication and access control are often combined into a single operation, so that access is approved based on successful authentication, or based on an anonymous access token. Authentication methods and tokens include passwords, biometric scans, physical keys, electronic keys and devices, hidden paths, social barriers, and monitoring by humans and automated systems.

References

↑ R. Shirey (August 2007). Internet Security Glossary, Version 2. doi: 10.17487/RFC4949 . RFC 4949 . Retrieved May 19, 2023.
↑ Richard E. Smith. Elementary Information Security. p. 150.
↑ Daley, R. C.; Neumann, P. G. (1965). "A general-purpose file system for secondary storage". AFIPS '65 (Fall, part I): Proceedings of the November 30--December 1, 1965, fall joint computer conference, part I. ACM Press. p. 213. doi:10.1145/1463891.1463915.
↑ "Managing Authorization and Access Control". Microsoft TechNet. 2005-11-03. Retrieved 2013-04-08.
↑ "P.S.I. Pacer Software, Inc. Gnet-II revision 3.0". Communications. Computerworld. Vol. 18, no. 21. 1984-05-21. p. 54. ISSN 0010-4841 . Retrieved 2017-06-30. The new version of Gnet-II (revision 3.0) has added a line-security mechanism which is implemented under the Primos ACL subsystem.
↑ Grünbacher, Andreas. "POSIX Access Control Lists on Linux". Usenix. Retrieved 12 December 2019.
↑ wurtzkurdle. "Why was POSIX.1e withdrawn?". Unix StackExchange. Retrieved 12 December 2019.
↑ Trümper, Winfried (February 28, 1999). "Summary about Posix.1e". Archived from the original on 2008-07-23.
↑ "Red Hat Enterprise Linux AS 3 Release Notes (x86 Edition)". Red Hat. 2003. Archived from the original on 2013-12-02. Retrieved 2013-04-08. EA (Extended Attributes) and ACL (Access Control Lists) functionality is now available for ext3 file systems. In addition, ACL functionality is available for NFS.
↑ "NFSv4 ACLs". FreeBSD. 2011-09-12. Retrieved 2013-04-08.
↑ "Chapter 8 Using ACLs and Attributes to Protect ZFS Files". Oracle Corporation. 2009-10-01. Retrieved 2013-04-08.
↑ Grünbacher, Andreas (May 2008). "Native NFSv4 ACLs on Linux". SUSE. Archived from the original on 2013-06-20. Retrieved 2013-04-08.
↑ Grünbacher, Andreas (July–September 2010). "Richacls – Native NFSv4 ACLs on Linux". bestbits.at. Archived from the original on 2013-03-20. Retrieved 2013-04-08.
↑ "ACLs". Linux NFS.
↑ "Mapping Between NFSv4 and Posix Draft ACLs".
↑ "vfs_nfs4acl_xattr(8)". Samba Manual.
↑ "[MS-ADTS]: Active Directory Technical Specification".
↑ Swift, Michael M. (November 2002). "Improving the granularity of access control for Windows 2000". ACM Transactions on Information and System Security. 5 (4): 398–437. doi:10.1145/581271.581273. S2CID 10702162.
↑ J. Barkley (1997) "Comparing simple role based access control models and access control lists", In "Proceedings of the second ACM workshop on Role-based access control", pages 127-132.
↑ G. Karjoth, A. Schade and E. Van Herreweghen (2008) "Implementing ACL-based Policies in XACML", In "2008 Annual Computer Security Applications Conference".