What are access control lists ACL and capability lists?

Access Control List vs CapabilityList

Leave a comment Go to comments

In Access Control List [ACL] each object has a list of [action, user-list] tuple.

table 1: Access Matrix

For example, in the above diagram File1 & File2 would have following ACL:

File1: [ [read, {user1}], [write, {user2}] ]

File2: [ [read, {user1}], [write, {}] ]

On the other hand, in the capability list system which is a counter-part of ACL system, a user is associated with a list of [action, object-list] tuple.

For example, for user1, capability list would be :

User1: [ [read, {file1,file2}], [write, {}] ]

User2: [ [read, { }], [write, {file1} ] ]

While same access matrix can be represented in both ACL and capability list, in this note we will first understand some subtle differences of these two representation and try to find out why ACL is better in Object Centric perspective. In order to evaluate this, we would introduce few administrative actions that has to be carried out in a access control model.

Worth to mention that ACL and Capability List is just different representations of Raw Access Matrix and they does not denote new type of Access Control model, although over time, ACL has been evolved due to its effectiveness in system having large number of object [ex. OpenStack Swift].

Add user: A access control model should be capable to adding new user.

Remove user: A user should have to be removed when needed from the access control system.

Add object: New object or new resource may have to be added.

Remove object: An existing object could be removed from the system.

We are leaving adding andremoving permission from our discussion which is not necessary to compare between ACL and Capability list.

Now,lets see what happens when these actions are carried out in both ACL and Capability System.

Table2: Administrative Action [adding/removing of user/object] vs Required Changes in ACL / Capability System

In a ACL system, when a user is being added, it may require that the newly created user gain some privileges on existing objects instantly or later. For example, we assume the worst case such that in a ACL based system, a user is added and it gets read, write action on each existing object. The situation is shown in following figure.

So, the ACL list would be changed as following:

File1: { [read,[user1, user3]], [write, [user2, user3]]}

File2: { [read,[user1, user3]], [write, [user3]]}

So, the point to make here is that in ACL based System, on adding / removing a user, there may be a changed required in the ACL of existing object. On the other hand, similarity, in the capability system, there may be a change required in the Capability list of existing user on addition or removal of an object. The situation is shown in Table2.

Now, from figure 2, we can speculate that if a system has fewer user centric operations [ex. add user, remove user, change in user’s privilege label] and more object centric operation [ex. add object, remove object] ACL is good for it, because in this case ACL required less changethan its corresponding Capability list.

An excellent example of it is the reason why OpenStack Object Storage [Swift] uses ACL for maintain its Access Control. Swift is build for storing a large number of objects which require large number of object centric operation and less number of user centric operation.

To make ACL more powerful swift uses ACL with Role instead of ACL with user-identity. That means, while in our given example, we have used user’s identity in the ACL list, Swift uses user’s rolesin its ACL. A Role based ACL is shown in following figure. Note that here Role is used just as a way to group users.

Role based ACL used in Swift.

Where Capability List is Good fit:

So, we understand where and when ACL is good choice. On the contrary of the previousexplanation, is Capability modela good fit in the system where more user centric action is required? The answer is NO. I explain it in terms of enterprise system.

because, Capability model cannot address following issues which are very required in real system:

1. Many users in an organization get same level of privileges because of his /her position in the organization. In Capability Based system it means duplication of same capability list for many users.

2. In enterprise system, a user privilege level may change frequently [ex. user may get promoted]. This is hard to manage in capability list.

3. many many others.

The point is that in the Enterprise system, there are many other user related actions [ ex. delegation, Separation of duty, etc] which cannot be supported by Capability List.

To keep our focus on, we would not talk about User Centric Access Control models [ex. RBAC, DAC etc]. Rather, now we would check some of the ACL System.

Like this:

Like Loading...
Categories: Access control Concepts

Access Control Matrix and Capability List

Blog

There is often confusion about the relationship between access control matrix and capability list or access control list when in fact these can be captured in a single image for clarity and simplicity purposes. You can think of access control matrix as a security access table which combines ACL and user capability list to define who can access what and to which degree. In the ACM, columns define objects and assigned privileges or ACL, rows list users or subjects, and relationships between rows and columns define user capabilities or UCL.

Access Control Lists

The original Multics protection mechanism was based on the idea of adding an access control list or ACL to each file, protecting the right to open that file. An access control list is a list of user, access-access rights pairs. Consider the access matrix:

AliceBobCarolDaveaaabbbcccddd
R/WRR-
RR/WR
RRR/WR
R/WR/WR

We can express the same access constraints given in the above matrix with the by attaching the following access control lists to the four files shown:

aaa -- Alice:R/W, Bob:R, Carol:R

bbb -- Alice:R, Bob:R/W, Carol:R, Dave:R/W

ccc -- Alice:R, Carol:R/W, Dave:R/W

ddd -- Bob:R, Carol:R, Dave:R

Note, with access control lists, that we only list users who have access to some file, omitting from the list those users who have no access. It should be immediately clear that access control lists have the potential to completely encode every aspect of the access matrix.

Sparse Matrices

In the field of numerical analysis, a matrix where most of the elements are zero is called a sparse matrix. Conventional [non-sparse] matrices can be efficiently stored as two-dimensional arrays, but in computations involving very large numbers of sparse matrices, memory can be used more efficiently by storing each matrix as a list of non-empty rows, where each row is stored as a list of nonzero elements.

It should be immediately clear that the access-control-list idea is really just a sparse-matrix representation for the access matrix. We only store an access control list for objects that someone has access to, and the only entries in the list are entries for current users.

Default Access Rights and Groups

Access control lists, in the basic form described above, are only efficient if the average file is accessible to only a few users, for example, if most files are private. The basic access control list idea was enhanced very early in the development of systems by adding a special entry for the default access rights. Typically, this was put at the very end. If we use the distinguished name Others for this, the above example can be reformulated as:

aaa -- Alice:R/W, Bob:R, Carol:R

bbb -- Bob:R/W, Dave:R/W, Others:R

ccc -- Alice:R, Carol:R/W, Dave:R/W

ddd -- Bob:R, Carol:R, Dave:R

The Others entry is at the end of the list so that a linear search will find individual ownership before it finds an entry that matches everyone. The basic model of the access control list had no such concept of ordering. The list was just a set of pairs.

Once the idea of creating a single "wild card" group was hit upon, it was natural to invent group memberships for users. This can shorten the access control lists, but there are two costs:

  • First, it means that the algorithm for searching for a particular user's access rights to a particular file is no longer simple. Instead of searching for that user in the ACL, we must search for that user and all groups that user is a member of.

    Second, it means that multiple ACL entries may refer to a particular user. A user might match the ACL under his or her own personal identity as well as under any of several groups that user belongs to. Do we give the user the union of all access rights from the different matches? Do we give the user the intersection of the access rights? Do we search from the start of the list and give the user the first rights that match?

It is worth noting that the access rights system of Unix is a degenerate form of the access control list idea. Each Unix file has a 3-entry access control list, where the first entry lists just one user [the owner], while the second entry lists a group [the group], and the third entry is the wildcard [others].

Fully general access control lists have been added in various ways to various versions of Unix. Unfortunately, these have not been entirely compatable, but a standard is emerging. Typically, the shell command getfacl gets the access control list of a file and setfacl sets the access control list. The man page acl gives more details, including pointers to a variety of ACL manipulation routines.

Windows NT and .NET both use access control models that owe a considerable debt to the Multics ACL idea. Some security standards consider ACLs to be the minimum reasonable access rights enforcement mechanism.

Access Control Lists

  • Authors
  • Authors and affiliations
  • HakkiC.Cankaya
Reference work entry
DOI: //doi.org/10.1007/978-1-4419-5906-5_770
  • 3 Citations
  • 652 Downloads
How to cite

Video liên quan

Chủ Đề