Content-Dependent Access Control

ACM SIGOPS Operating Systems Review, vol 25 no 2 (April 1991), pp 63-70.

ACM SIGOPS Operating Systems Review, vol 25 no 2 (April 1991) pp 63-70.Domino Report: B1/IC/5 Content-Dependent Access Control

J.D. Moffett & M.S. Sloman 6 December 1990 Imperial College of Science Technology and Medicine

Department of Computing, 180 Queen’s Gate, London SW7 2BZ, UK

Email: jdm@uk.ac.ic.doc, mss@uk.ac.ic.doc

ABSTRACT

Content-dependent access control, where the access decisions depend upon the value of an attribute of the object itself, is required in many applications. However problems arise in an object-based environment, because obtaining the value of an object's attribute requires an operation upon the object. We discuss the conceptual and performance implications of introducing content-dependent access control, and suggest how the problems can be avoided in some cases by using a domain-based approach to access control.

1INTRODUCTION

'Content-dependent' access control is a form of access control required by many applications. It is defined as access control where the decision to allow access to an object depends upon the value of attributes of the user and target objects themselves. This is a discussion of the problems which arise when we attempt to fit it into an object-based view of access control.

1.1.Background

We start from the basic concepts of domains for grouping objects, a reference monitor to decide and enforce access decisions, and access rules as the basis on which it makes its decisions.

Domains

A domain [Sloman 1989] is an object whose purpose is to represent a set of objects which may be resources, workstations, modems, processes, etc, depending on the purpose for which a particular domain is defined. One attribute of a domain is its object set, which is a set of identities of objects which are referred to as domain members. In a distributed system, the domain object and its members may themselves be distributed. See figure 1.

Figure 1 Domains in a Distributed System

Reference Monitor

Figure 2 illustrates the reference monitor [Anderson 1972], as refined in [ISO 1989]. It consists of two separate components, an Access Control Enforcement Facility (AEF) and an Access Control Decision Facility (ADF), where the AEF intercepts the operation request, asks the ADF for a decision on whether the request is authorised and then enforces it. In a distributed system the components of the reference monitor may (and where capabilities are

used, will) be distributed.

Figure 2 Reference Monitor

Access Rules

An access rule [Moffett 1990] consists of three components: a User Domain which defines a set of user objects; a Target Domain which defines a set of target objects; and an Operation Set.See figure 3. For each operation request, the reference monitor searches for an access rule which authorises the request, i.e. one where the invoking user is a member of its User Domain, the target object is a member of its Target Domain, and the operation is a member of its Operation Set. If such an access rule can be found, the reference monitor allows the request, but not otherwise.

Figure 3 An Access Rule

2

ADDITIONAL CRITERIA

Decision making using simple access rules is based only on the domain memberships of user and target objects. Decision criteria may also be based on system and object attributes.

2.1.System Attributes

There is a need to be able to make access decisions which are dependent on some system attributes. Examples are the constraint of access to defined dates and times, and to defined user terminals, e.g. no access outside 9 a.m. - 5 p.m., Monday - Friday, or no access from remote sites. These constraints imply an extension to access rules, but they do not give rise to any major problems, since it is a reasonable assumption that the information needed is readily available to the reference monitor as a system function. We do not discuss this form of access control further.2.2.

Object Attributes

Objects are assumed to have attributes which represent data or state information, e.g. date of creation and length of a file object; or current salary, role and authorisation level for an object representing a user. Access control decisions based on the values of these attributes - content-dependent access control - is a desirable facility in many applications, but can give rise to a number of problems. First we give an example.2.3.

Example 1 - Transaction Authorisation Levels

A financial organisation carries out payment transactions in two stages. One user creates a Transaction object using a Create operation. No special authorisation is required for this. A second user then actions the payment using a Pay operation on the Transaction object. The Pay operation requires special controls. The organisation's policy is:

1a) A user can perform the Pay operation on a Transaction only if his financial authorisation

level is greater than the amount of the transaction.A typical design approach to this might be to define a numeric Authorisation_Level attribute in the User object and an Amount attribute in the Transaction object, and create an access rule:1b)All users may perform Pay on those Transaction objects where the value of the user's

Authorisation_Level attribute is greater than the value of the Amount attribute in the Transaction object.3PROBLEMS OF CONTENT-DEPENDENT ACCESS CONTROL

3.1.

Finding Out Attribute Values

The basic problem with content-dependent access control is that it adds a fundamental factor to the access decision. In our previous model the reference monitor could make a decision from the information in the operation message and the access rules. Now it cannot make a decision about access without first of all doing Read operations to find out the value of the user and target objects' attributes. See figure 4.

Target Object

User

2. Read user attribute

3. Read target attribute

Figure 4 Reference Monitor Obtains Attributes by Reading Objects

The Reference Monitor has to perform a Read operation on both user and target objects in order to make its decision about the operation request. The resulting overhead depends on the implementation approach for the Reference Monitor. But note that the overhead would be incurred with every invocation of the operation. In some implementations access control can be optimised by performing it only at the time of binding to a file or database of objects. We cannot apply it when using content-dependent access control, as each decision depends upon the attributes of individual objects, which can change as a result of previous operations.3.2.

Trusting User Objects

Let us assume that the purpose of access control in our examples is to protect target objects from users, and not vice versa. Then access decisions which depend on attributes of user objects can only be made safely if we can rely on the value of those attributes. One safe situation is when the user's system is trusted. In that case we can trust the system to attach the correct attribute value to the operation request for the reference monitor to use. See figure 5.One of the Read operations required of the reference monitor has now been eliminated.

Target Object

User

2. Read target attribute

Figure 5 Trusted User System - Reference Monitor Only Reads Target Object However, in general user objects execute in unprotected workstations in a network and cannot be trusted. They are in a position to alter their own attributes, and can therefore influence the access control decision by ensuring that their attributes match the access rule requirements. It might be thought that there is a possible solution to the problem of untrusted user systems by requiring the user object to have its attribute values authenticated by a trusted authentication service. However, since we must assume that an untrusted user's attributes can be changed at will, there is no gain in this.

An alternative approach is to create another object within the trusted target system to record important attribute values of the user object, e.g. in the same database if the target objects are represented by a database. It is then safe to depend upon the user attribute values. There are still two problems associated with this approach: it is necessary for the Reference Monitor to read the user's attribute values, as well as those of the target object, at every access attempt;and it may not be practical, if the user's attributes change frequently, to maintain consistency between the two representations of the user's attributes.3.3.

ACL Implementation with User Attribute Values

We can further reduce the problem by taking an implementation-oriented approach. If Access Control List objects (ACLs), local to the target object, are used to perform the access checking the problem becomes more manageable. See Figure 6. If the ACL is local to the object, then the cost of the Read operation is greatly reduced.

User

Figure 6 ACL Performs Attribute Check

The figure does not show clearly where the ACL is located. If it is implemented as an attribute of the target object, no extra read operation is required. However, we are considering an implementation of access control in which ACLs are held as attributes of domain objects, reflecting the fact that most requirements for access control can be specified in relation to an object's domain memberships [Moffett 1990]. Then for any decision which depends upon the attributes of an individual object it will be necessary to read its attributes before the access decision is made.

3.4.Reference Monitor Complexity

A simple access rule only requires the reference monitor to recognise the User, Target Object and Operation Identity fields in an operation request. Two extensions to its complexity are required for content-dependent access control

?It must extract a user attribute value from the operation request message, as discussed in

3.2 or access another object representing the user.

?It must perform a Read to obtain the target object's attribute.

Since it is a requirement that a reference monitor should be as simple as possible [Anderson 1972], the additional complexity is undesirable.

3.5.Application Based Approach

The other possible approach is to abandon any attempt to provide a system-based approach to content-dependent access control, and build controls of this kind into the code of the target object itself. It has, of course, immediate access to its own attributes. The user object would still need to pass its attribute values with the operation message. The disadvantage of an application-based approach is that it will now be difficult or impossible to provide a single interface to all access control specification; the system's access rules will be separate from the application's access control.

4EXPRESSING CONTENT-DEPENDENT DECISIONS IN TERMS OF DOMAINS

In some cases, such as example 1 above, the application's need for access decisions to be expressed in terms of the attributes of objects seems unavoidable. However, there are other cases where it may be possible to recast the requirement into straightforward domain-based access rules. Consider the following example.

4.1.Example 2 - Divisional Personnel Responsibilities

There is an organisation divided into several divisions, including Drivers and Mechanics divisions, with a personnel department which serves all of them. Members of Personnel Division are allocated responsibility for divisions. The requirements for access control include the following:

2a)Users in Personnel Division may read personnel records of the division for which they are responsible.

We can define the division in which a person works, and the area of responsibility of a member of Personnel, as attributes (Division & Responsibility) of the Employee object. Then these are possible access rules:

2b)Users may Read Employees where

(User.Division = Personnel & User.Responsibility = Employee.Division).

2c)Users may Read Employees where

(User.Division = Personnel & User.Responsibility = Drivers &

Employee.Division = Drivers).

Version 2b is clearly preferable to 2c but, like the first example, requires enough intelligence in the access control system to make a comparison between the values of two attributes. An access rule such as 2c) will have to be repeated for every Division in the organisation. It is only practical because there is only a small number of possible values of the attribute.

Since there is only a small number of Divisions, we can contemplate a domain-based solution, avoiding content-dependent rules entirely. We can set up a domain for each Division: Drivers_Dom, Mechanics_Dom and Personnel_Dom to which each employee is allocated appropriately; and two subdomains of Personnel_Dom called Drivers_Resp and Mechanics_Resp to which members of Personnel are allocated according to their responsibility. Then the requirement can be satisfied by access rules such as:

2d)Members of Drivers_Resp may Read objects in Drivers_Dom.

Employees

Figure 7 Domain Based Design

Figure 7 shows a domain-based solution which requires no content-dependent specification at all. It may be that many of the access control requirements, which would previously have been thought to depend on the 'contents' of objects, can be dealt with in this way.

4.2.Untrusted Domains

The comments made in section 2.2 above also apply to domain membership, where the object representing the domain is in an unprotected system. It is essential that the domains used to specify access decisions should be in trusted systems. The situation is not as bad as it might sound, because the domain object does not have to be in the same system as its member objects.

Using our example, even though the Driver objects may be in an untrusted system, it is possible for the Drivers_Resp domain can be set up in the trusted system. If there is a trusted system of user authentication, then the home system can control who has access. It cannot, of course, control what happens to the information when it arrives in the untrusted system, and therefore even this level of access control may be unacceptable.

5CONCLUSIONS

We can reach the following conclusions from this discussion:

?Content-dependent access control which uses the attributes of a user object is dependent on trusting the user's system. A partial solution to it when the user system is untrusted would be to use domain based access rules at the user end only.

?In any case content-dependent access control adds complexity to the access control system, and probably performance problems also. Rather than provide a general system facility it may be preferable to build it into applications where it is necessary.

?In many cases content-dependent access control is rendered unnecessary by the use of domains to represent the properties of users. Simple domain-based access rules can then be used. This is only practical where there is only a small number of possible values of the attribute, and impossible where the attribute may have a large number of numeric values.

6REFERENCES

[Anderson 1972]Anderson J.P., Computer Security Technology Planning Study, ESD-TR-73-51, vol 1 AD-758 206, ESD/AFSC Hanscom, AFB Bedford, Mass, Oct 1972. [ISO 1989]ISO, Security Framework III: Access Control Framework, ISO/IEC JTC1/SC21 N4206 (Draft, November 1989)

[Moffett 1990]Moffett J.D. Sloman M.S. & Twidle K.P., Specifying Discretionary Access Control Policy for Distributed Systems, Computer Communications, vol 13 no 9, pp 571-580 (November 1990).

[Sloman 1989]Sloman M.S. & Moffett J.D., Domain Management for Distributed Systems, in Meandzija & Westcott (eds), Proc of the IFIP Symposium on Integrated Network Management, Boston, USA, May 1989, North Holland, pp 505-516.