Access control list

An access control list (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.[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 Bob to only read it.

Implementations

Many kinds of systems implement ACLs, or have a historical implementation.

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,[2] OpenVMS, Unix-like, and Mac OS X operating systems. 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.

Most of the Unix and Unix-like operating systems (e.g. Linux,[3] BSD, or Solaris) support POSIX.1e ACLs, based on an early POSIX draft that was withdrawn in 1997. Many of them, for example AIX, FreeBSD,[4] Mac OS X beginning with version 10.4 ("Tiger"), or Solaris with ZFS filesystem,[5] 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[6] and the more recent Richacls,[7] which brings NFSv4 ACLs support for Ext4 filesystem.

PRIMOS featured ACLs at least as early as 1984.[8]

In the 1990s the ACL and RBAC models were extensively tested and used to administer file permissions.

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. 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)[9] showed that RBACm and ACLg are equivalent.

In modern SQL implementations, ACL 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.[10]

See also

References

  1. ↑ RFC 4949
  2. ↑ "Managing Authorization and Access Control". Microsoft Technet. 2005-11-03. Retrieved 2013-04-08.
  3. ↑ "Red Hat Enterprise Linux AS 3 Release Notes (x86 Edition)". Red Hat. 2003. 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.
  4. ↑ "NFSv4 ACLs". FreeBSD. 2011-09-12. Retrieved 2013-04-08.
  5. ↑ "Chapter 8 Using ACLs and Attributes to Protect ZFS Files". Oracle Corporation. 2009-10-01. Retrieved 2013-04-08.
  6. ↑ Grünbacher, Andreas (May 2008). "Native NFSv4 ACLs on Linux". SUSE. Archived from the original on 2013-06-20. Retrieved 2013-04-08.
  7. ↑ Grünbacher, Andreas (July–September 2010). "Richacls - Native NFSv4 ACLs on Linux". bestbits.at. Retrieved 2013-04-08.
  8. ↑ "P.S.I. Pacer Software, Inc. Gnet-II revision 3.0". Communications. Computerworld. 18 (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.
  9. ↑ 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.
  10. ↑ G. Karjoth, A. Schade and E. Van Herreweghen (2008) "Implementing ACL-based Policies in XACML", In "2008 Annual Computer Security Applications Conference".

Further reading

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.