An access control list stores the access rights to an object as a list with the object itself. An ACL therefore corresponds to a column of the access control matrix and states who may access a given object. The entries in an ACL are called access control entries (ACEs). ACLs are a typical security feature of commercial operating systems.
Management of access rights based only on individual subjects can be rather cumbersome. It is therefore common practice to place users in groups and to derive access rights also from a user’s group. The Unix access control model is based on simple ACLs each having three entries that assign access rights to the principals user, group, and others. ACLs are a ﬁtting concept for operating systems that are geared towards managing access to objects. If, however, you want an overview of the permissions given to an individual user, e.g. to revoke that user’s permissions, you face a laborious search through all ACLs.
No matter how you implement the access control matrix, managing a security policy expressed by such a matrix is a complex task in large systems. In particular, it is tedious and error-prone to establish that all entries in such a matrix are as desired. Moreover, access control based only on subjects and objects supports a rather limited range of security policies. Further information, which may be appropriately included in an access control decision, may refer to the program the subject invokes to access the object. This is not a novel idea at all, as you can see from the following comment on access control in the Titan operating system, developed in Cambridge in the early 1960s:
In particular, it was possible to use the identity of a program as a parameter for access-control decisions as well as, or instead of, the identity of the user, a feature which Cambridge people have ever since regarded as strange to omit.
Published on Fri 02 January 2009 by Anthony Norton in Security with tag(s): acl