Access control

While proper authentication guarantees that acting entities in a system really are who they claim to be, this in itself does not say anything about what these entities may, or may not, do. To enforce security policies to that effect we need access control.

Access control can be found in many places and implemented on many levels. Most operating systems have access control mechanisms on the file level. Many database systems allow access control rules to be specified for how the data in the database may be accessed. There are also many examples of applications that implement their own access controls, independently of other mechanisms that may exist in a system.

The most basic access control policy is to allow full access to anyone properly authenticated, and to deny access completely otherwise. This model is perfectly suitable in some environments, but is too unsophisticated for many others. There are several approaches to how access control can be organized in order to best express and implement underlying security policies. Later on we shall look at some of the most important of these.

General principles

  
Figure 6.2: Abstract access control model

The International Organization for Standardization (ISO) together with the International Electrotechnical Commission (IEC) has published a suite of documents specifying and standardizing various security-related frameworks. Figure 6.2 is adapted from [ISO96] in this suite. The figure shows an abstract view of access control using the standardized terminology. The initiator is the person or program that attempts to access some target. When access control is in place, an access enforcement function (AEF) is interspersed in the path of the access request. The AEF calls upon an access decision function (ADF) to get information about whether an access request should be granted or not.

The ADF may use information from a number of sources in order to compute its result. Access control information (ACI) may be associated with

The initiator.

Initiator ACI may be attributes such as the (access control) identity of an individual, information about group membership, information about active roles, and sensitivity and integrity markings.

The target.

Examples of target ACI are target access control identity, sensitivity and integrity markings, and identity of a container object holding the target.

The access request.

To access a target is to perform some kind of operation on it. Access control information for operations can include things such as classification (e.g. read, write) and an integrity level required for use of an operation.

A request operand.

Operands other than the target may be involved in an operation, for instance information to be written to a file. Such operands may also have ACI-like integrity or sensitivity markings.

In addition, the ADF may also take contextual information into account when making its decision. Examples of contextual information include the time of day, the location of the initiator, the route a request has traveled, the strength of authentication used, and system status. Contextual information of this kind can be used to enforce policies restricting access to certain time periods, secure terminals, secure communications channels, or to strongly authenticated initiators.

Getting a working system

In order to create an access control system in a real system, the abstract entities described above need somehow to be instantiated. An initial step is to establish representations and data structures for storing access control information in the system. Such representations are highly system dependent, and must be carefully crafted to allow access control policies to be expressed in the desired way. There must also be implementations of an AEF and an ADF.

Given these basic building blocks, the operation of an access control system can be divided into two main parts. One is the operation of the system itself, the granting or denying of access requests as required. However, a prerequisite for the proper workings of this is that ACI has been assigned correctly to the various entities in the system. This management and administration of the access control system itself form the second main part.

Management of an access control system is performed by a Security Domain Authority (SDA), or by agents of the SDA that have been delegated the authority to perform management operations. Typical management operations include things such as installing, changing, and revoking ACI to initiators, operations, and targets. This also includes the important step of defining ACI attributes and their value domains.

Once ACI is in place, the system can begin operations. The main difficulty to solve when realizing an AEF and an ADF is how to make ACI available to these entities in a secure manner. In order for the ADF to make the correct decision, it must be unequivocally certain that the ACI it has to evaluate really has been properly assigned to the entities involved in the operation. For this purpose, the concept of bound ACI is introduced. The process of binding provides the necessary proof of association between some ACI and an entity. For any access request, there will be ACI bound to the initiator, the target, and the request itself.

Classification of access control systems

The framework for access control described in section 6.3.1 is a very general one within which most systems can be described. By looking at the way ACI is used, it is possible to classify access control systems using just a few main schemes. It is also possible to classify access control systems according to underlying access control policies.

ACI usage schemes

We briefly describe here four ACI usage schemes. It should be noted that most access control systems allow for more than one scheme to be used. The usage schemes we describe

are:

Access Control Lists.

Access control lists (ACLs) is a widely used scheme. An access control list is associated with a target (and becomes target-bound ACI to the ADF.) The list consists of initiator/operation pairs naming an individual, group or role that may perform a specified operation on the target. When using ACLs, necessary initiator-bound ACI is an individual, group our role identity.

ACLs provide for a very finely grained level of access control. However, if the number of possible initiators is large, or if the set of initiators varies frequently over time, maintenance of the lists can become very demanding.

Capabilities.

Capabilities are self-contained initiator-bound ACI that name a target and a set of permitted operations on that target. A capability is analogous to a parking permit. In the same way a parking permit shows that the holder may park vehicles (an operation) at some specified parking space (a target), a capability shows the ADF the operations the initiator may perform on the target.

Capabilities are issued and bound to an initiator by an SDA (security domain authority). Target-bound ACI contains information about existing SDAs and what operations each SDA may authorize.

Labels.

In a label-based access control scheme, security labels may be assigned to initiators, targets, operations, and data in transfer. The ADF compares the labels of the entities in a request and makes its decision according to some set of rules.

As an example, consider a system where all information is assigned one of the labels Unclassified, Confidential, and Secret. Users are also assigned corresponding labels, usually called clearances. ADF rules can then state that someone with Secret clearance may read information labeled Unclassified, Confidential, and Secret. However, everything written by a user with Secret clearance must also be labeled Secret. Likewise, a user with Confidential clearance may read Confidential and Unclassified material, but can only write Confidential or Secret data.

Labels can be arbitrary complex entities and are often structured so as to facilitate comparison.

Context based access control.

To implement some policies, it is desirable to take into account contextual information pertaining to an access request. Such information can be the time of day, the location of the initiator, the route which the request has traveled, or the current system load or status. Often such restrictions are imposed generally for all initiators.

In order to enforce contextual rules, the ADF uses a context control list. This list contains pairs of context specifier and allowed operations. The ADF can obtain context information both from initiator-bound and target-bound ACI, as well as independently.

It is important to note that these schemes are only examples of how the inner workings of an access control system can be structured. The use of one or the other scheme has no direct relation to what access control policies can be expressed and implemented. However, the ease of policy implementation varies for different policy/scheme combinations.

Access control policies

In this section we look at some common overall access control policies. We also relate these policies to those access control schemes which are most often used to implement them.

Mandatory access control.

The name Mandatory Access Control, MAC, is perhaps something of a misnomer as access control should never be ``optional''. However, MAC is a long used and widely accepted term to denote an overall policy where all ACI is maintained by a central SDA. This centralized approach has advantages in that it gives a common view over how access control policies are implemented.

The label-based access control scheme is often used to implement MAC.

Discretionary access control.

While it can be said that for MAC, the SDA ``owns'' all resources, Discretionary Access Control, DAC, introduces a concept of resource owner. Under DAC, it is the resource owner that manages ACI for a resource. A well-known example of DAC is the Unix operating system where each user can decide the availability of her files and directories to other users. This approach greatly reduces the need for centralized access control administration and provides great flexibility. However, under DAC it is often difficult to enforce overall access control policies as one must rely on each and every resource owner to individually implement policies as they apply to the resources owned by her.

Discretionary access control is often implemented using the access control scheme where each target-ACL is managed by the target owner.

Role-based access control.

Role-based access control (RBAC) is a way to express access control policies using organizational roles as an origin. The basic idea is that when an individual acts within an organization she does so in the capacity of a role defined within that organization. Using roles, and relationships between roles, an organization can be described abstractly. Access control information is then added to the abstract organizational model, i.e. authorizations are assigned to roles. In this way access control policies can be completely expressed in a way that does not involve specific individuals. In a second step, individuals are assigned to the roles in which they are allowed to act. In a third step, a user who wishes to perform some task activates a role (to which she has been assigned) appropriate for the task and thereby indirectly obtains the permissions given the role.

Role-based access control can be implemented using several schemes. The most straightforward scheme is to use access control lists naming roles as initiators. In distributed systems a capability-based scheme is often used where users obtain a set of capabilities when a role is activated. RBAC models often also include constraints on how roles may be used, calling for the contextual access control scheme to be incorporated in the implementation.