3.3. Access Control
In a computer system, users typically wish to read and write files, browse directories, and execute programs. In multi-user systems, different users will be authorized to access different resources. In other words, there generally will be a security policy that determines the resources to which each user has access.
An authorization service (also known as a reference monitor or access control mechanism) is a computer program that enforces an authorization policy (or access control policy). Any computer system that offers any level of protection will ensure that the authorization service intercepts all user requests to access resources in order to ensure that all user requests are properly authorized before a user gains access to the requested resource. Most authorization policies directly or indirectly specify the set of authorized requests. The standard implementation of an authorization service denies any request that is not authorized by the policy. (There are other possible approaches, such as to explicitly prohibit certain requests, with the default response to grant a request unless it is denied.)
Figure 3.1 illustrates a generic architecture for an authorization service. A policy enforcement point (PEP) intercepts all access requests and forwards them to the policy decision point (PDP). The PDP consults the access control policy, decides whether the request is authorized, and returns its decision to the PEP. If the decision is to deny the request, the PEP may generate a suitable message for the user. If the decision is to permit the request, the PEP will make the object available to the user.
Figure 3.1. A generic access control architecture.
Typically, the PDP will require certain information to make a decision. In particular, the PDP will need to know who is requesting access to what. In many systems, the PEP is responsible for gathering this information and forwarding it to the PDP with the request, although this is not the only possibility. Generally the “who” question is answered by authenticating each user of the system and associating each process that a user runs with his or her identity. The “what” question is answered by consulting information maintained by the operating system about the resources it protects. It is customary to refer to the user as the subject and the resource as the protected object or object.
Generally, the PDP will also need to know how the subject wishes to interact with the object. The more common interactions between subject and object include read, write, and execute. The exact operational meaning of these generic interactions will be dependent on the type of object and other contextual information.
An access control model provides a method for encoding an access control policy and states the conditions that must be satisfied for an access request to be granted. In other words, it provides a blueprint for an access control mechanism. The conditions that determine whether a request is authorized may be expressed as security properties. One way to express the conditions that determine whether a request is authorized is to specify the state (more accurately the protection state) of the system following the request. The state of the system is a snapshot of security-relevant features in the system. Usually, it is sufficient to consider the state to be the set of access requests that have been granted by the access control mechanism.
In this section, we will examine some of the important theoretical models for access control. Such models are used as the framework for the development of authorization services in operating systems and applications such as relational database management systems.
3.3.1. Access Control Based on Subject–Object Relationships
Perhaps the simplest type of access control mechanism is one based on the relationship that exists between the object and the subject. The Unix and VMS operating systems are perhaps the best known examples of this type of approach.
Every resource, including printers and disc drives as well as files and directories, is treated as an object and every object is associated with an owner and a group. A subject may belong to one or more groups. Every subject has a subject identifier (SID) and every group has a group identifier (GID). When a subject requests access to an object, the operating system determines the relationship that exists between the object and the subject by comparing the SID and the GIDs associated with the subject to the owner SID and GID associated with the object. Unix identifies three possibilities: the subject is the owner of the object, the subject belongs to the group associated with the object, or the subject is not the owner and does not belong to the group associated with the object. For convenience, we usually refer to these relationships as “owner,” “group,” and “world,” respectively.
Unix uses three generic access rights: read (r), write (w), and execute (x). Therefore, each object is associated with nine access rights; three for each of the three relationships that exist between subject and object. The access rights associated with an object are called an access mask or permission mask.
Internally, a permission mask consists of 9 bits; if a bit is set, the corresponding access right is granted. The permission mask is logically divided into three groups of 3 bits, where each group of 3 bits indicates read, write, and execute access, respectively. The three groups correspond to the owner, group, and world relationships, respectively. Unix programs (such as ls) display the permission mask symbolically, for example, rwx r-x r-x is used to denote the access mask 111 101 101.
3.3.2. Protection Matrix Model
A protection matrix is an abstract representation of an access control policy. The matrix represents those access requests that are authorized by the system. A protection matrix is arranged as a two-dimensional array, with each row labeled by a subject and each column labeled by an object. A matrix entry in the row labeled s and column labeled o determines the authorized actions for s with respect to o. Hence, if the matrix entry for s and o contains read, a request from s to read object o is authorized. In other words, the protection matrix encodes triples of the form subject–object–action; object–action pairs are often referred to as permissions or capabilities. The protection matrix has proved to be a powerful and abiding abstraction for the design of protection mechanisms in operating systems and application software. Many authorization services, such as the security reference monitor in Windows 2000 and the security policies in Java, are based on the protection matrix.
Implementing an Authorization Service
We may use a protection matrix in order to implement an authorization service. This service will receive access requests and make a decision as to whether the request should be granted. The request will only be granted if it is authorized by the protection matrix. In order to use a protection matrix, it is necessary to know the following: the identity of the subject making the request, the identity of the object that the subject wishes to access, and the type of interaction that the subject wishes to have with the object.
The identity of the subject is determined by examining the security information associated with the subject (the process that generated the access request). This information will typically be a user account associated with the authenticated user that caused the process to be created. When making the request, the identity of the object will be specified by the subject and will refer to some resource protected by the operating system. Finally, the type of interaction requested is usually represented as an access mask, which is a binary string of n bits, where n is the number of access rights supported by the system. If a particular bit is set in the access mask, then the corresponding access right is being requested.
Given a user account identifier s, an object identifier o, and an access mask, the authorization service finds the matrix entry corresponding to s and o and compares the access mask in the request with the one in the matrix entry. If every bit that is set in the requested mask is also set in the matrix entry, then every access right that has been requested is authorized by the matrix and the request may be granted.
However, an authorization service rarely uses a protection matrix to store authorization information. This is because in a large computer system with many subjects and objects, the memory requirements for such a data structure would be prohibitively large. Moreover, many entries in the matrix may be empty, meaning that large amounts of memory allocated for the storage of the protection matrix would remain unused. Clearly this represents a poor use of such a vital computing resource.
Access Control Lists
It is more usual to implement the matrix as a set of access control lists (ACLs) or capability lists. These structures have the feature that only relevant matrix entries are stored, with empty matrix entries being ignored. An access control list is associated with an object and consists of a number of entries defining the rights assigned to each subject for that object. Conceptually, an access control list is a list of access control entries. Each entry in the list identifies a subject and a set of access rights. In other words, each access control entry in an access control list for object o specifies how the subject identified in the entry can interact with o.
In order to implement an authorization service using access control lists, the same information is required as for a protection matrix implementation. In order to check whether a request should be granted, the authorization service first finds the access control list for the requested object. It then checks each access control entry to see if it refers to the requesting subject. If it does, the requested rights are compared with the rights in the access control entry. Access is granted if every requested right is in the access control entry and denied otherwise.
Capability Lists
In contrast to ACLs, a capability list is associated with a subject. Conceptually, a capability list is a list of permissions, each identifying an object and the right that has been assigned to the subject for that object. In other words, each permission in a capability list for a subject specifies how that subject may interact with the object specified in the permission.
Security Groups
In a large user population, many users will share certain characteristics. In a commercial setting, perhaps the most obvious characteristic would be job description or function. All users with the same job description are likely to have similar access to certain objects; clearly, it would be laborious to create the same matrix entries (or access control entries) to these objects for each of these users. Hence, many authorization systems include the ability to specify security groups. The idea is that certain access rights to certain objects can be assigned as one block to a group subject.
However a user may be associated with a number of different groups. When a user typically logs on to a computer system, he or she is associated with identifiers both for his or her own user account as well as for any group to which he or she belongs. Strictly speaking, user identifiers and group identifiers are used to label the rows of a protection matrix or the entries in an access control list. That is to say, the rows of a protection matrix actually represent the authorizations for a particular principal.[5]
[5] Saltzer and Schroeder define a principal to be the entity to which authorizations are granted.
Access Control Lists and Multiple Principals
A number of different options exist for authorization systems based on access control lists when a subject may be associated with a number of different principals. Some systems only permit each object to be associated with a fixed number of subjects. In other words, each object has a fixed-length access control list. Unix is an example of such a system, in which each object has an access control list with three entries: one for the object owner, one for the group associated with the object, and one for every other user (sometimes referred to as “the world”). Windows 2000, in contrast, permits access control lists of arbitrary length.
We can also decide whether the authorizations of a subject are represented by the most relevant principal or by the aggregation of the authorizations for each principal associated with that subject. Unix chooses the first option: If the subject is the owner of the requested resource, only the authorizations of the owner principal are considered when deciding whether to allow the request. If the subject is not the owner but belongs to the group, then only the authorizations of the group principal are considered. If the subject is neither the owner nor belongs to the group, then the authorizations of the world principal are considered. This means that an owner could have less access than a member of the group, although the owner can always change the access control list so that he or she has all access rights. In contrast, Windows will check every entry in an access control list in deciding whether an access request should be granted.
Negative Authorization
In recent years, we have seen the emergence of authorization mechanisms that support negative authorization policies, in which certain actions are explicitly prohibited. Such authorization policies are particularly useful for enforcing exceptions to a more general policy. For example, we may wish to grant access to a particular set of objects to many different subjects; clearly, the most convenient way of doing this is to create a group for those subjects and then authorize the group to access those objects. However, if there is one member s of the group g who should not be allowed access to one particular object o, it is rather cumbersome to enforce this requirement without negative authorizations. The only option in this case is to remove s from g and then grant s access to all the objects to which members of g have except o. A less burdensome way of implementing this requirement is to keep s in the group and simply prohibit access by s to o. Windows 2000 permits the inclusion of negative access control entries in access control lists. XACML, the recent standard for XML-based authorization policy specification and enforcement [6], also supports negative authorizations.
Nevertheless, negative authorizations are not without their problems. In particular, it becomes extremely difficult to reason about the overall security policy. Another problem is that negative authorizations give rise to policies that may have conflicting authorizations. That is, a positive and negative authorization may exist for the same request. In the example just given, s will have a positive authorization to access o from his or her membership of g, but also a negative authorization explicitly denying him or her access to o. The intention in this case is that access should be denied, but how is the authorization service to know this?
In order to address these types of issues, policy conflict resolution mechanisms are defined. The most obvious and widely used mechanism is to insist that a negative authorization always take precedence over a positive one. This is known, naturally, as the “deny-overrides” algorithm in XACML. There are other possibilities, such as “permit-overrides” and “first-applicable.” The latter assumes that authorization rules are processed in a particular order and that the first relevant authorization is to be used. Windows 2000 has a hybrid approach that groups access control entries in a particular order and implements what might be called a “deny-overrides-if-first-applicable” algorithm. This ordering of access control entries is first determined by the creator of the access control entry, with entries created by the creator of the object (rather than ones inherited from the object’s container) taking precedence. Within each such group of entries, negative entries precede positive entries.
Windows 2000: An Illustrative Example
Windows 2000 (and its successor Windows XP) is perhaps the most widely used operating system in the world. A Windows 2000 installation will include one or more domains, each of which contains users, machines, and resources. A user is authenticated to a domain using Kerberos. Each domain has at least one Kerberos authentication server that also acts as a ticket-granting server. A user logged on to a domain account benefits from single sign-on: Whenever he or she requests a network service, any further authentication is performed without any additional input from the user (based on the domain’s prior authentication of the user).
When a user logs on and authenticates successfully to a Windows 2000 domain, the local security authority (LSA) obtains SIDs (via the messages exchanged in the Kerberos protocol) for the user and for each security group to which the user belongs. This information is obtained from a network directory service, Active Directory, which stores information about all entities in the system. The SIDs form part of the access token, which contains all security information related to the authenticated user.
When the user executes a program, a process is created that inherits a copy of the access token. The security reference monitor (SRM) uses this token and an object’s security descriptor to determine whether an access request should be granted. The security descriptor contains a discretionary access control list (DACL), which comprises zero or more access control entries (ACEs). Each entry includes an SID (called a trustee in Windows 2000 literature) and a set of access rights. ACEs can be used to deny access rights as well as grant access rights. In other words, Windows 2000 supports negative authorizations.
When a user makes an access request, the object manager, which acts as the PEP, constructs a requested access mask indicating which access rights have been requested by the user, obtains the user’s access token and the requested object’s DACL, and forwards the request to the SRM, which acts as the PDP. The SRM traverses the DACL, matching SIDs in the access token to trustees in the DACL’s ACEs. During this traversal, the SRM constructs a granted access mask indicating the access rights for which the user is authorized. After inspecting each ACE, the SRM compares the requested access mask and the granted access mask: If they match, access is granted and the SRM returns a positive decision to the object manager. If the SRM reaches the end of the DACL and the two access masks do not match, the SRM returns a negative decision to the object manager.[6] The traversal of the DACL will terminate prematurely and a negative decision is returned to the object manager if any requested access right is contained in a matching negative ACE.
[6] In fact, the algorithm for deciding whether an access request is considerably more complicated. Windows 2000 includes the notions of restricted SIDs and impersonation access tokens, which affect the algorithm. The reader is referred to Microsoft’s Distributed Security Guide (http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/distrib/dsce_ctl_ajfg.mspx?mfr=true) for further details.
3.3.3. An Information Flow Policy for Confidentiality
We now consider a very different approach to authorization policies, in which access to resources is determined by the respective attributes of the subject and object. Much of the early research on secure computer systems was funded by the U.S. military. The prime concern of this research was to ensure the confidentiality of sensitive electronic resources. The research sought ways to mimic paper-based systems in which documents are stamped with labels such as “Confidential” and “Top Secret” and are filed securely according to their classification. A user is only allowed access to a document if his or her security clearance is as high as that of the document. In the late 1960s, the military began to fund research on implementing such an access control policy in computerized systems. Two important models from this period include the lattice-based model for information flow [7] and the Bell-LaPadula model [8].
The act of accessing an object can be regarded as initiating an information flow. In particular, reading an object causes information to flow from the object to the subject, while the flow is in the opposite direction if the subject writes to the object. An information flow policy specifies which information flows are authorized. As we might expect, an information flow policy for confidentiality requires that high-level information cannot flow to a lower level, for example, an unclassified user cannot read classified material.
In order to describe an information flow policy in formal terms, it is necessary to define a set of security labels L and a security function λ. The set of security labels is ordered, meaning that it is possible to compare two different security labels. A widely used set of security labels in military circles is {unclassified, classified, secret, top_secret}, where the ordering is defined to be unclassified < classified < secret < top_secret.
The security function λ is used to associate a security label with each subject and each object.[7] The information flow policy states that information may only flow from an entity e to another entity f if λ(e) ≤ λ(f). In other words, information flow between two entities obeys the ordering on the entities’ respective security labels. Hence, it is not allowed, for example, for information to flow from a top_secret source to a less secure entity. In contrast, information may always flow from an unclassified source.
[7] Formally, λ: S ∪ O → L; that is, λ is a function from the set comprising all subjects and objects to the set of security labels.
When we consider different interactions between subjects and objects we derive the following rules:
A subject s is authorized to read an object o only if the security label of s is at least as high as that of o. This is sometimes referred to as the no-read-up rule or simple security property [8].
A subject s is authorized to write to an object o only if the security label of o is at least as high as that of s. This is sometimes referred to as the no-write-down rule or *-property [8].
A word of explanation is required regarding write access. It is possible that a subject with top_secret clearance may (inadvertently) run a Trojan horse program that has been installed by an attacker. Such a program might attempt to write top_secret information to a less secure file. The no-write-down rule prevents the Trojan horse program from performing this action, limiting the damage that an attacker can inflict by installing such a program. (Of course, if the attacker can obtain top_secret access, then he or she can obtain the top_secret information anyway.) Another security compromise that the no-write-down rule prevents is that of a subject mistakenly writing sensitive information to an object with a lower security level. The classic example of this is printing top_secret documents on a printer that has an unclassified security label. (A request to print a document is usually interpreted as a request to write to a printer object.)
3.3.4. Bell-LaPadula Model
Clearly, it is unlikely that an information flow policy will be able to define all the authorization requirements of a computer system. Notice that an information flow policy authorizes access purely on the basis of labeling of the subject and object, and is independent of any ownership considerations. This is sometimes referred to as a mandatory access control policy. In practically all cases, no user should actually be authorized to write to a file with a higher security label, but the information flow policy does not prevent this from happening. Therefore, it is necessary to augment the mandatory information flow policy with a discretionary access control policy, defined by the object owners and implemented using a protection matrix.
The Bell-LaPadula model is perhaps the most famous of all access control models and has had a significant influence on the development of research into access control. It allows for the definition of a mandatory information flow policy and a discretionary access control policy. The first contribution of the Bell-LaPadula model was to formally define what it meant for a computer system to be in a secure state. A second contribution was to prove that it is possible to construct computer systems that only exist in secure states. That is, it is possible to build a computer system and define a security policy such that for all future points in time, the system is in a secure state.
The Bell-LaPadula model implements an information policy for confidentiality, and includes a protection matrix to further refine the information flow policy. The protection state, or simply state, of a computer system is a snapshot of all security-relevant information that is subject to change. The Bell-LaPadula model defines the state of the system to be (V, M), where V denotes the set of active triples.[8] V models those requests that have been granted and represents the set of objects that are in main memory currently in use by subjects. For example, if a request from s to read o is granted then the object is brought into main memory, which is modeled by adding the triple (s, o, read). It will become apparent that this is an important consideration in checking access requests.
[8] For ease of exposition, we assume that λ is fixed. In the most general form of the model, this is not the case, and λ is included as part of the state.
The Bell-LaPadula model defines three security properties. All triples in V must satisfy the simple security property and *-property. In addition, every triple in V must satisfy the discretionary security property, which requires that every granted request has been authorized by the protection matrix.
A state is said to be secure if it satisfies the discretionary, simple, and *-properties. In order to maintain the system in a secure state, it must not be possible to grant a request that would violate any of the three security properties. Hence, when a user makes an access request, the system must check both the access matrix to see that the request is authorized by the matrix and compare the security labels of the subject and object to determine whether the simple security property and *-property are satisfied.
The operating system is responsible for all state transitions and must ensure that each command that causes a state transition moves the system from a secure state to another secure state. Therefore, the operating system will contain a number of functions that implement security checks to ensure that the state transition results in a state that conforms to the security policy of the system.
3.3.5. Clark-Wilson Model
The Bell-LaPadula model was inspired by security requirements for military computer systems. In contrast, the Clark-Wilson model is concerned with commercial computer systems. Typically, the business processes of a commercial organization will have certain consistency constraints that must be satisfied. A banking application, for example, might include a process that transfers money from one account to another account. A consistency constraint in this case would be that the total amount deposited in the two accounts is the same before and after the transfer. It is vital that business processes ensure that all consistency constraints are satisfied.
A computerized business process is often called a transaction and comprises a sequence of operations that transform one state of a computer system to another.[9] Transactions are a central concept in data processing applications such as relational database management systems. A transaction is well formed if it transforms a consistent state into another consistent state. The Clark-Wilson model is concerned with ensuring that a commercial system is consistent with the business rules (or security policy) of the organization running that system.
[9] The state of a computer system is a rather broad and informal concept compared to that introduced in the description of the Bell-LaPadula model. It refers as much to the data and business objects in the system as the actual objects in main memory.
The model introduces the following concepts: constrained data items (CDIs), unconstrained data items (UDIs), and transformation procedures. A CDI can be thought of as a protected object. Clark and Wilson propose a model for protecting the integrity of CDIs and for ensuring that the transformation of a CDI is consistent with the related security policy. In contrast, UDIs are not protected. However, if a UDI is used as an input to a business process, it must first be transformed into a CDI in order to ensure that it cannot subsequently violate the integrity of the system.
In order to ensure the integrity of CDIs, users can only interact with CDIs through well-defined interfaces called transformation procedures (TPs). A TP can be thought of as a complex access operation, which changes the CDI in some way or into a different type of CDI. A TP may only interact with certain CDIs: It would make no sense for a TP that transfers money between two accounts to operate on CDIs that are not bank accounts, for example. Associating TPs with particular CDIs ensures that only well-formed transactions may be executed.
Moreover, only certain users are allowed to perform particular TPs. A bank clerk, for example, might be allowed to perform a TP that effects a transfer of funds from one account to another, but would not be allowed to perform a transformation procedure that authorized an overdraft. In other words, subjects are associated with TPs that determine what interaction they may have with CDIs. This enables an authorization policy to be specified. Clark and Wilson suggest that this can be achieved by defining relationships of the form (t, o) and (s, t, o), where t is a transformation procedure, o is a constrained data item, and s is a subject.
Certification Rules
The Clark-Wilson model proposes a number of certification and enforcement rules. The certification rules basically express a high-level generic security policy. The certification rules are:
Enforcement Rules
The certification rules are implemented by the enforcement rules. The enforcement rules are:
The Clark-Wilson model is not really an access control model in any formal sense. It more closely resembles a set of evaluation criteria. We can imagine assigning a security rating to a system based on the degree to which certification and enforcement rules were implemented. The model also provides a useful checklist when designing and developing secure applications.
3.3.6. Role-Based Access Control
A long-standing problem in practical security systems is the administrative burden of maintaining access control lists or other similar access control data structures. In a system with 1,000 users, 100,000 objects, and 10 access rights (a relatively small system by today’s standards), there are 10 × 1,000 × 100,000 = 109 possible authorization triples. Role-based access control (RBAC) is a relatively recent attempt to alleviate this burden. It achieves this by introducing the concept of a role, which acts as a bridge between users and permissions. The idea is that there will be far fewer roles than either users or permissions. Typically, roles are associated with job descriptions, although this is not the only possibility.
The basic concepts of RBAC are illustrated in Figure 3.2. The ANSI RBAC standard was released in 2004 [9]. It is based on earlier work by researchers at George Mason University and NIST, notably Ravi Sandhu [10]. The two main components are the core component, which does not include role hierarchies, and the hierarchical component, which does.
Figure 3.2. Core RBAC. From Sandhu et al. [10].
There is a set of users U, a set of permissions P, and a set of roles R. A permission is usually assumed to be an object–action pair, where an action is synonymous with an access right. Users are associated with roles using a user–role assignment relation UA. This relation is a set of pairs of the form (u, r), meaning that user u is assigned to role r. Permissions are similarly associated with roles using a permission-role assignment relation PA.
Users interact with an RBAC system by activating a session. Typically, the user authenticates to the system and chooses to act in one or more of the roles to which he or she is assigned. If s makes an access request for permission p during the session, the permissions of the session roles and their junior roles are considered. If the requested permission is among them, the access request is granted.
In a sense, RBAC can be thought of as an extension of the Clark-Wilson model. Permissions represent an association between a CDI and TP. Roles introduce an extra level between users and TPs, and are used to reduce the number of associations that need to be maintained.
RBAC further reduces the administrative burden by introducing the idea of a role hierarchy, which is modeled as a directed acyclic graph in which the roles are nodes. In other words, the role hierarchy is represented as a binary relation RH on R. The transitive, reflexive closure of this relation defines a partial ordering on the set of roles.
The basic idea is that a role high up in the hierarchy will inherit the permissions of lower roles, without having to be explicitly assigned to those permissions. Clearly, this significantly reduces the number of permissions that need to be assigned to more senior roles, thereby reducing the administrative overheads in an RBAC system. Of course, this introduces an overhead into the access-checking algorithm, because it is necessary to consider the permissions of all junior roles when making a decision.
RBAC is now widely supported in commercial systems, such as Oracle, Sybase, Windows 2003, and Solaris. An RBAC profile exists for XACML and it is widely used in workflow management systems. The interested reader is directed to the recent book by Ferraiolo et al. [11], which provides an excellent overview of RBAC and its applications.