Computer Communications, vol 13 no 9, pp 571-580 (November 1990)
`
`SPECIFYING DISCRETIONARY ACCESS CONTROL POLICY FOR
`DISTRIBUTED SYSTEMS
`
`Domino B1/IC/3.1
`18 September 1990
`
`Jonathan Moffett, Morris Sloman and Kevin Twidle
`Department of Computing
`Imperial College,
`180 Queen's Gate,
`London SW7 2BZ.
`Email jdm@uk.ac.ic.doc, mss@uk.ac.ic.doc, or kpt@uk.ac.ic.doc
`
`ABSTRACT
`
`This paper discusses a proposed framework for specifying access control policy for very large
`distributed processing systems. These typically consist of multiple interconnected networks
`and span the computer systems belonging to different organisations. This implies the need for
`cooperation between independent managers to specify access control policy. The policy
`specification should permit interaction between organisations while limiting the scope of what
`objects can be accessed and what operations can be performed on them.
`
`The large numbers of objects in such systems make it impractical to specify access control
`policy in terms of individual objects. The paper explains how domains can be used to group
`objects and structure the management of access control policy. Access Rules are introduced as
`a means of specifying the access rights between a domain of user objects and a domain of
`target object in terms of the permitted operations as well as constraints such as user location
`and time of day. The use of domains for specifying the scope for which authority can be
`delegated to managers or security administrators is explained and the issues related to
`implementing access rules using capabilities or access control lists are discussed.
`
`Keywords
`
`Access control policy, security management, authority, domains, access control lists,
`distributed systems.
`
`23/8/91
`
`1
`
`Petitioner Apple Inc. - Exhibit 1026, p. 1
`
`

`

`INTRODUCTION
`1 .
`Access control is concerned with ensuring that users and processes in a computer system
`access computer based resources in a controlled and authorised manner. Resources must be
`protected from unauthorised access and access permission must be assigned only by users or
`managers with authority to do so. We consider only logical access control and not issues
`relating to physical access control such as locks, secure rooms etc. The DoD trusted computer
`evaluation criteria [DoD 1985] define two kinds of logical access control. Discretionary access
`control permits managers or users to specify and control the sharing of resources with other
`users. Mandatory Access Control enforces polices which are built into the design of the
`system and cannot be altered except by installing a new version of the system. For example in
`'multi-layer' security systems, data cannot be read by a user with a lower security classification
`than has been assigned to the data. Mandatory policy is particularly applicable to military
`environments, whereas discretionary policy typically applies to commercial, industrial and
`educational environments. This paper is concerned with the latter.
`We are concerned with very large distributed processing systems which typically consist of
`multiple interconnected networks and span the computer systems belonging to a number of
`different organisations. Authority cannot be delegated or imposed from one central point, but
`has to be negotiated between independent managers who wish to cooperate but who may have
`a very limited trust in each other. They may wish to give each other access to their computer
`systems which is closely controlled both in the scope of the objects which can be accessed and
`the operations which may be performed on them. (We use the term object in this paper to
`denote a computer resource such as a file or process as well as a user or manager).
`The numbers of objects in a very large distributed system can total hundreds of thousands. It
`is impractical to specify access control policy in terms of individual objects and so there is a
`need for grouping objects and applying a policy to a group of objects. For example the same
`policy may apply to all people in a department or to the set of files pertaining to an application.
`We introduce domains for grouping objects in section 2 and explain their use of as a means of
`structuring and managing the specification of access control policy, by means of Access Rules,
`in section 3.
`Access control policy relates to authority i.e. power which has been legitimately obtained and
`to how authority is delegated. We have identified distinct management roles which apply to
`commercial organisations, each with different authority, and in section 4 introduce the concept
`of delegation of authority, as a means of the controlled creation of Access Rules.
`A number of implementation issues arise from the concept of Access Rules. They are
`discussed in section 5.
`
`2 . DOMAINS
`Domains provide a flexible and pragmatic means of specifying boundaries of management
`responsibility and authority. They are described in detail in [Sloman 1989], but are
`summarised here. A domain is an object which represents a collection of objects which have
`been explicitly grouped together for a purpose i.e.to which a common management policy
`applies. The objects may be resources, workstations, modems, processes, etc, depending on
`the purpose for which a particular domain is defined, and each object has a globally unique
`identifier. A domain has an attribute called an Object Set, which defines the set of member
`objects. The minimum representation of a member object is a its unique identifier which can be
`used to locate the object by means of a location service. The domain may also cache object
`addresses and may optionally hold a local name for use by human users to refer to an object.
`An object is referred to as a member of a domain if its identity is a member of the domain's
`Object Set. Objects may be a member of more than one domain at a time. Domains are
`persistent even if they do not contain any objects - it must be possible to create an empty
`domain and later include objects in it.
`Domains do not encapsulate the objects themselves - managers or external objects may interact
`directly with an object in a domain.
`
`23/8/91
`
`2
`
`Petitioner Apple Inc. - Exhibit 1026, p. 2
`
`

`

`Since domains are themselves objects, they may be members of other domains. An object is an
`indirect member of a domain Dx if it is a member of a domain Dy which is a member or indirect
`member of Dx.
`In addition to the Object Set attribute, domains may have other attributes. We envisage
`attributes which express possible domain policies, such as constraints on domain membership.
`Also, some implementations may require a domain-related attribute for all objects, a Domain
`Set attribute recording the identities of all domains which contain the object.
`2 . 1 Domain Relationships
`The possible relationships between domains can be defined in terms of the relationships
`between their members as shown in Fig. 2.1. The notation is that round boxes are domains
`and squares or triangles are objects.
`Disjoint
`Two domains are defined to be disjoint if they have no members in common.
`Overlap & Subset
`Two domains overlap if there are objects which are members of both domains, as shown in
`Fig. 2.1a. A special case of overlapping occurs when the object identities in one domain's
`Object Set are a subset of those in another (Fig. 2.1b).
`Subdomain
`If a domain object is a member of another domain, it is referred to as a subdomain of that
`domain as shown in Fig. 2.1c. The representation of subdomains in Fig. 2.1c can lead to
`ambiguity between subsets and subdomains and an alternative representation is shown in Fig.
`2.1d. In this paper we will be only discussing subdomains so will use the representation of
`Fig. 2.1c.
`
`D1
`
`O2
`
`O1
`
`D2
`
`O4
`
`O5
`
`O3
`
`O6
`
`a) Overlap Relation
`
`D1
`
`O1 O2
`
`D3
`O6 O7
`
`O3
`
`O5
`
`O4
`
`O8 O9
`
`D2
`
`D4
`(b) Subset Relation
`
`O1
`
`D2
`O3
`
`O2
`
`D3
`
`O6
`
`O7
`
`O5
`
`D4
`
`O8 O9
`
`O4
`
`D1
`
`=
`
`O1
`
`O2
`
`D1
`
`D2
`
`D2
`O3
`
`O4
`
`O5
`
`D3
`
`O6
`
`D3
`
`O7
`
`D4
`
`D4
`
`O8 O9
`
`(c) Subdomain Relation (Ambiguous)
`
`(d) Subdomain Relation (Unambiguous)
`
`Figure 2.1 Domain Relationships
`
`23/8/91
`
`3
`
`Petitioner Apple Inc. - Exhibit 1026, p. 3
`
`

`

`2 . 2 Operations on a Domain
`The main operations which can be carried out on a domain are:
`Creating and Destroying Objects
`Create an Object in a Domain - This creates an instance of an object and adds its identity to the
`Object Set of a domain and is the way an object is made known to the system. Management of
`objects in domains requires that all objects, except for one or more root domains, should
`always exist in domains. Note that the Create operation may involve loading code onto a
`computer and creating a process as an object. In general, manufacture of an object and
`installing or connecting it to the distributed system will require some services outside the
`domain framework.
`Destroy an Object in a Domain - This removes the object's identity from the domain's Object
`Set and destroys the object instance.
`It is an application decision whether a separate Destroy operation is required, or whether it is to
`be achieved by Removing the object from all domains; also, whether Destroy should be
`permitted on an object which is a member of more than one domain. These policy decisions
`can be represented as Domain constraints.
`Operations Relating to Domain Membership
`Include Object in a Domain - includes an object into a domain by adding its identity to the
`Object Set of the domain. It does not affect the state of the object or its membership of other
`domains, except that the object updates its Domain Set. A domain object can be included into a
`domain to form a sub-domain.
`Remove Object from a Domain - removes an object from a domain by removing its identity
`from the Object Set. There is no effect on the state of the object except that if it maintains a
`Domain Set, this must be updated.
`It is an application decision whether Remove is permitted if it is not a member of any other
`domain's Object Set; the effect is then to destroy it.
`List Objects in a Domain - returns a list of the members of the Object Set of a domain.
`
`ACCESS RULES
`3
`3 . 1 Access Control Enforcement
`We use the Reference Monitor concept, as described in [Anderson 1972, DoD 1985], to model
`an access control system. The function of a reference monitor is to enforce the authorised
`access relationships between subjects (users) and objects of a system. It is a trusted
`component of the system. All operations requested to be carried out on an object are
`intercepted by the reference monitor, which only invokes the operation if the access is to be
`allowed. See Figure 3.1.
`The figure illustrates that, in general, access control is carried out by the system, and not by the
`target object itself, although the reference monitor could be implemented by the object. The
`operation of the Reference Monitor is transparent to the user provided the access is authorised,
`but if the access is not authorised the operation is not invoked and the user is informed by a
`failure message.
`
`23/8/91
`
`4
`
`Petitioner Apple Inc. - Exhibit 1026, p. 4
`
`

`

`User
`
`Operation
`Message
`
`Object
`
`a) User View of an Operation
`
`User
`
`Operation
`Request
`Message
`
`Rejection
`
`Reference Monitor
`Access Check
`
`OK?
`
`÷
`
`X
`
`Operation
`Message
`
`Object
`
`b) Access Checking by a Reference Monitor
`
`Figure 3.1 Reference Monitor Access Check
`3 . 2 Motivation for Access Rules
`Access Rules are the means for specifying access control policy and are an adaptation of
`Lampson's Access Matrix [Lampson 1974] for large distributed systems. Figure 3.2 shows a
`portion of an Access Matrix which indicates, for each user-target pair in the system the
`operations which the user may perform upon the target object. The default access is zero if
`none is shown.
`
`Target
`Objects
`Users
`
`User1
`
`User2
`
`.......
`
`Obj1
`
`Read
`
`Obj2
`
`Read,
`Write
`
`Write
`
`UserN
`
`Read
`
`.......
`
`.......
`
`.......
`
`.......
`
`ObjN
`
`Read
`
`Read,
`Write
`
`Figure 3.2 Portion of an Access Matrix
`The Access Matrix is unsuitable for large distributed systems for several reasons:
`i)
`It becomes too large when the number of objects can be in the hundreds of thousands.
`Sparse matrix storage mechanisms can alleviate the problem to some extent, but it is
`necessary to partition the matrix. Domains provide a possible method of partitioning.
`ii) The matrix, as a centralised data structure, assumes global knowledge of the user and target
`objects which are in the system, but it is impractical to maintain this global information in a
`distributed system spanning multiple independent organisations, so the full matrix can
`never be constructed.
`iii) The access matrix is based on the assumption that access rights are specified between
`individual users and target objects. It does not permit policy to be specified with respect to
`groups i.e. to domains. The manager may not even know the members of the domain at
`the time the policy is formulated, and the policy specification should not require changes
`when the individual user and target objects in the system change.
`
`23/8/91
`
`5
`
`Petitioner Apple Inc. - Exhibit 1026, p. 5
`
`

`

`iv) We require a means of specifying policy in terms of roles performed by users in an
`organisation rather than the users themselves. For example the access rights for a
`departmental manager should not relate to the person holding that position, but rather to the
`position or role itself. This means the rights do not have to be changed if the person is
`moved to another role.
`3 . 3 Definition of Access Rules
`A simple Access Rule is shown in Figure 3.3. It specifies a User Domain, which identifies
`the set of possible users who can perform operations; the Target Domain, which identifies the
`set of possible target objects on which operations can be performed, and the Operation Set ,
`which are the authorised operations a user can perform on a target. This may be a subset of the
`operations which the target objects support. Extensions to the simple access rule are discussed
`in section 3.6.
`
`DomX
`
`DomY
`
`User
`Domain
`
`OpA
` ...
`OpZ
` ...
`
`Operation Set
`
`Target
`Domain
`
`Figure 3.3 An Access Rule
`In our model, access rules are the means by which the Reference Monitor determines whether
`to authorise an operation request, which is a triple consisting of (user, target, operation name).
`We assume that an authenticated user identity is available to the monitor as part of the message
`which requests the operation. The monitor authorises a request if an access rule exists which
`applies to the operation request i.e. if the user object is in the set defined by the user domain of
`the rule, the target object is in the set defined by the target domain of the rule and the operation
`is in the operation set of the rule, as indicated in Figure 3.4. There may also be extensions to
`access rules to allow for decisions based on time of request, user location and operation
`parameter values.
`
`User
`X
`
`Operation
`
`Target
`
`OpZ
`
`Y
`
`Operation
`request
`
`DomX
`
`DomY
`
`Access
`Rule
`
`X
`
`Y
`
`OpA
` ...
`OpZ
` ...
`
`Operation Set
`
`Target
`Domain
`
`User
`Domain
`
`Figure 3.4 An Access Rule which Applies to an Operation Request
`Objects in a subdomain, by default, “inherit” the access rules applying to direct and indirect
`parents. In Fig. 3.5, objects in domain D2 inherit the access rule applying to the parent domain
`D1 so can perform operations (OpA & OpB) on objects in domains D3 and D4 as the latter is a
`subdomain of D3. There may be more than one access rule which satisfies a particular request,
`e.g. as a result of an object's membership of overlapping domains. This indicates that authority
`has been granted via more than one route.
`
`23/8/91
`
`6
`
`Petitioner Apple Inc. - Exhibit 1026, p. 6
`
`

`

`D1
`
`D2
`
`U1
`
`U2
`
`U3
`
`OpA
`OpB
`
`O1
`
`O2
`
`D3
`
`D4
`
`O3
`
`O5
`
`O4
`
`Figure 3.5 Inheritance of Access Rules
`Some operations affect more than one object which implies the need for multiple access rules to
`authorise the operations. For example the operation to include an object in a domain requires
`an access rule for the object to be included as well as one for the domain into which it is to be
`included.
`3 . 4 Granularity of Access Rules
`The User Domains in access rules are role domains which have individual users as members.
`This ensures that the rules remain valid even if users change their roles in an organisation.
`However, there will be a requirement to set up access rules for an individual user, e.g. to allow
`the user to access his personal files, electronic mail, etc. Defining an access rule for an
`individual target object can be achieved by creating a domain and including the target object in
`that domain, but this would be laborious if different access rules are required for many
`individual objects. Our general model of domain expressions therefore allows for the
`specification of individual users and target objects. There may be some implementation costs
`associated with this, and other projects place restrictions on the facility. The Andrew project
`[Satyanarayanan 1989] allows individual users, as well as domains, to be specified in their
`Access Control Lists (ACLs), but the finest granularity for the ACLs of file objects is the
`Directory.
`3 . 5 Example of Access Rules
`We use as an example the Payroll Department of an organisation. It consists of roles for
`people, and a directory of payroll files, see Figure 3.6. We assume that the Payroll Manager
`(viewed as being outside the department he runs and not shown in Fig. 3.6) can create
`whatever Access Rules he wishes.
`
`Payroll_Dept
`
`PS
`(Payroll_Supervisor)
`
`Ann
`
`PC
`(Payroll_Clerks)
`
`Bill
`
`Cheryl
`David
`
`Payroll_Files
`
`Payroll_Master
`
`Payroll_Input
`
`Payroll_Output
`
`Figure 3.6 Domain Structure of the Payroll Department
`The Payroll Manager may not know or understand the names of the files in the Payroll_Files
`Domain or what are the names of the files which will be added to it in future. However, he has
`delegated to the Payroll Supervisor the task of maintaining the files, so an expression of this
`delegation policy is to give the Payroll Supervisor the ability to Create, Read and Write files in
`
`23/8/91
`
`7
`
`Petitioner Apple Inc. - Exhibit 1026, p. 7
`
`

`

`that Domain. His policy is also to allow the whole Payroll Department to Read the
`Payroll_Files. These policies are expressed by the two Access Rules illustrated in Figure 3.7.
`
`Payroll_
`Supervisor
`
`Payroll_
`Dept
`
`Create
`Read
`Write
`
`Read
`
`Payroll_
`Files
`
`Figure 3.7 Example Access Rules
`The access rules do not name the user or target objects, and so we cannot tell directly from
`them whether the access by a particular user to a particular target will be allowed. To interpret
`the access rule we have to know the domain structure, as shown in Figure 3.6, which can be
`used to derive a partial access matrix as shown in Figure 3.8.
`
`Target
`Objects
`
`Users
`
`Ann
`
`Bill
`
`Payroll_
`Master
`
`Payroll_
`Input
`
`Create,
`Read, Write
`
`Create,
`Read, Write
`
`Payroll_
`Output
`Create,
`Read, Write
`
`Read
`
`Read
`
`Read
`
`Read
`
`Read
`
`Cheryl
`
`Read
`
`David
`
`Read
`
`Read
`
`Read
`
`Figure 3.8 Partial Access Matrix Derived from Access Rules and Domain
`Structure
`Even if the Access Rules do not change, the matrix will cease to be a valid and complete
`description of the management access policy as soon as the membership of any of the Domains
`changes. For example, if Cheryl is replaced by Charles as a member of the Payroll_Clerks
`Domain or Payroll_Print is introduced into the Payroll_Files Domain, a new matrix would have
`to be to be constructed, but the access rules shown in Figure 3.7 would still be valid.
`3 . 6 Access Rule Extensions
`The simple access described so far specifies users or targets in terms of a domain name.
`However there is a need to specify more complex sets of objects in terms of a general domain
`expression which allows for the specification of individual users and target objects, set
`operations, restrictions on the interpretation of indirect domain membership and constraints on
`the applicability of access rules.
`
`Set expressions
`a)
`Domains and subdomains are a powerful means of expressing hierarchical membership and set
`union. If domain DomA contains DomB and DomC, then an Access Rule applying to DomA
`applies to the union of the Object Sets in DomB and DomC. However, it provides no means of
`expressing other basic set operations such as Set Difference and Set Intersection. Set
`Difference can express groups of objects such as 'all users in Payroll Dept except the Payroll
`Clerks', and 'all files in Payroll_Files except Payroll_Master'. Set Intersection can express
`groups such as 'all files which are in Payroll_Files and also in Personal_Data' (where we
`assume that Personal_Data is a domain of files subject to the Data Protection Act).
`
`23/8/91
`
`8
`
`Petitioner Apple Inc. - Exhibit 1026, p. 8
`
`

`

`It would be possible to use domain manipulation operations to create a new domain with the
`
`required membership e.g. DomA = (DomB « DomC), and refer to DomA in the access rule.
`
`However, the access rule then applies to membership of DomB and DomC at the time DomA is
`created and not at the time the access rule is checked. Static enumeration of objects at some
`point in the past may not be what is required. Set operations in access rules would be
`evaluated at the time the rule is checked.
`
`Limiting Indirect Domain Membership
`b)
`In the normal case an object is interpreted as being a 'member' of a domain if it is either a direct
`or an indirect member of it . This uses the full power of subdomains and is likely to be used in
`most cases. However, there may be situations in which we wish to prevent an Access Rule
`applying to indirect members of a domain. Therefore we need a notation which allows us to
`specify in an Access Rule that domain 'member' should be interpreted only as a direct member
`e.g. by suffixing the name with an exclamation mark.
`
`Constraints in Access Rules
`c)
`Another extension needed to the simple access rule is to permit the expression of a constraint
`on its applicability in terms of time of day, date, location of user etc. For example, it is quite
`common in many organisations to permit access to various objects only during normal office
`hours or to set up an access rule which expires after some time or only becomes valid in the
`future. Access to some resources may only be permitted to a particular user such as a salesman
`who is using a local terminal but when he is using a terminal at a customer's site he will have
`access to only a restricted set of resources or services.
`We assume that the Reference Monitor has available information about the User's environment
`(date and time of request, source of origin, etc), and the parameters of the operation.
`The possible general constraints in Access Rules, their method of representation and their
`implementation are all subjects for further study.
`
`Logging Switch in Access Rules
`d)
`A Security Audit Facility requires logging of both authorised and unauthorised operations. It is
`assumed that the Reference Monitor will provide it on all unauthorised operations, but there
`may also be a selective need for information on authorised operations also. For example all
`changes to access rules performed by a security administrator should be logged. One means
`of controlling this would be by a logging switch in Access Rules, which could be turned On in
`order to trigger the Reference Monitor to provide the Security Audit Facility with input.
`Adequate controls are required to prevent unauthorised switching Off.
`3 . 7 Removal of Access
`The prompt removal of access authority when necessary is an essential aspect of access
`control. There are a number of methods of achieving this:
`a) It is simple to express the exclusion of a particular user from accessing a target domain at the
`time an access rule is set up by means of a domain expression such as (Users_X \ Users_Y),
`which excludes members of Users_Y from access which they would have been permitted as
`members of Users_X. Note, however, that this will not override another Access Rule which
`allows members of domain Users_Y to have access. Similarly, a Target domain expression
`may specify (Files_X \ Files_Y).
`b) Negative Rights, which override any positive rights, have been used in some systems as a
`means of rapidly and selectively revoking access to sensitive objects [Satyanarayanan 1989].
`This greatly complicates the semantics of an Access Control system and can introduce inherent
`contradictions [Tygar 1987]. We therefore conclude that they should not be introduced into
`our model and so we only permit positive authorisation.
`c) Destruction or modification of an access rule will not prevent access if there is another
`remaining rule which permits access. Determining which access rules permit access can be
`complicated because typically the user or target object is a member of several domains which
`are subdomains of ones to which access rule refer. Tools and reporting facilities are therefore
`
`23/8/91
`
`9
`
`Petitioner Apple Inc. - Exhibit 1026, p. 9
`
`

`

`needed to permit a security administrator to determine what target domains a user can access
`and what users can access a particular target domain. The use of these tools would be adequate
`for routine removal of access rules, but searching a large system for relevant access rules may
`be rather slow.
`d) Denying access to an individual user in an emergency should be performed not by alteration
`of Access Rules but by suspension or deregistration of the user. It is instant and effective and
`does not add complications to the system.
`There are thus a number of different strategies which can be applied depending on the
`circumstances.
`
`4 . DELEGATION OF AUTHORITY
`4 . 1 Management Roles
`Access control policy relates to authority i.e. power which has been legitimately obtained and
`to how authority is delegated. We have identified four typical roles, which apply to
`commercial organisations, each with different authority:
`i) An owner of an object has the legal power to perform any feasible operation on it
`(including giving away ownership), together with the responsibility for operations which
`are performed on the object. There are of course limitations to this power. For example an
`owner of personal data may not disclose it except under the terms of the Data Protection
`Act, and the owner of petroleum spirit at a bulk distribution plant must ensure that an
`automated system dispensing it to tanker lorries does so in accordance with certain safety
`regulations. Restrictions of this kind have to be represented in computer systems as
`mandatory constraints, and are beyond the scope of this paper.
`Ownership could be shared or held by a committee or a board of directors. Note that the
`owner is not necessarily the user who creates an object, just as the bank clerk who creates
`an account for a customer is not the owner of the account.
`ii) A manager has been delegated management authority for objects by the owner. In general
`managers can perform any operations, including management operations, on an object but
`may have some limitations on their authority. For example a manager may not be able to
`pass on his own management authority.
`iii) In many commercial organisations a policy of separation of authority applies. The job of
`issuing access rights to users is delegated by an owner or manager to a security
`administrator. However the security administrator does not usually have access rights to
`the target objects for which he/she gives rights.
`iv) Normal users are given authority to use objects but not to manage them. A user cannot
`normally delegate any authority which he holds.
`We envisage different organisations defining other roles to suit their particular structures. The
`roles are specified as domains which define the authority pertaining to the users which are
`members of the domain.
`4.2
`Scope of Authority
`Access permissions are given and removed by creating, destroying and modifying access rules.
`The operations Create, Destroy and Read are needed on access rules. A Modify operation
`could be defined using a compound of these.
`Authority is delegated by creating access rules for manager or security administrator domains.
`However it is still necessary to control the flow of authority. A security administrator must be
`prevented from creating an access rule for users or targets over which he has no authority.
`Thus owners, managers, and security administrators have a user scope which is a domain of
`users to whom they can delegate authority and a target scope which specifies the target domains
`to which they are permitted to delegate authority.
`For example a Security Administrator domain has two attributes, a SA_User_Scope which
`defines the users who are administered, and a SA_Target_Scope which defines the target
`objects to which he can give access. He can create access rules to allocate access rights within
`
`23/8/91
`
`10
`
`Petitioner Apple Inc. - Exhibit 1026, p. 10
`
`

`

`these scopes. We can achieve separation of authority by ensuring a Security Administrator is
`not a member of the user scope over which he has authority. He cannot then give himself
`access rights.
`Users also need to specify access rules to permit colleagues etc. to access resources which are
`considered personal to them, for example to share files for cooperative working. One solution
`would be to consider a user to have the combined role of security administrator of a personal
`domain - see section 5.6.
`In addition to specifying Access Rules, managers and users need to be able query the system,
`within their scope of authority, to determine what access is permitted. Managers and security
`administrators need to be able to analyse the system to determine inconsistencies such as
`inaccessible domains. Typical reports required for managing and auditing the security policy
`include:
`• All objects to which selected user have access
`• All users who can access selected objects
`• All failed access attempts
`•
`Selected logging of authorised accesses.
`
`IMPLEMENTATION ISSUES
`5 .
`The above section has described Access Rules as a means of specifying access control policy.
`This is essentially being proposed as the user view of security policy, which must then be
`reflected in an underlying implementation which makes use of access control mechanisms to
`implement the policy.
`The main implementation issues, which should be hidden from users, are:
`• How to store Access Rules - whether they should be associated with the user objects, target
`objects or independent of both.
`• How to implement the reference monitor in a distributed system.
`• How to translate from the user view (access rule) to the implementation mechanism being
`used.
`5 . 1 Implementation Requirements
`
`Validity
`a)
`It is essential that the underlying implementation should make access control decisions which
`are consistent with the user view of domain-based Access Rules. When an Access Rule is
`created, modified or destroyed, the effect of the change must be reflected in access control
`decisions. It may be permissible in some circumstances for the effect to be delayed (e.g. until
`the following day, in the case of non-urgent changes), but this must be predictable. In addition
`when an object is included in or removed from a domain, or a new object is created, then the
`object's access authorisations (either as user or target) which derive from membership of the
`domain must change accordingly.
`
`Performance
`b)
`The overhead introduced for validation of authorised operation requests must be minimal if the
`system is not to degrade.
`The overhead in updating access authorisations must be tolerable for domain membership
`changes. It is thought that the contents of user domains will change relatively infrequently
`compared to those of target domains which contain objects such as temporary files.
`Changing access control policy by updating access rules, or obtaining status reports will be
`relatively infrequent and do not always have to take immediate effect, so higher overheads can
`be tolerated.
`
`23/8/91
`
`11
`
`Petitioner Apple Inc. - Exhibit 1026, p. 11
`
`

`

`5 . 2 Representing Individual Users
`In our proposed implementation, an individual user is represented in the system by a "login"
`domain with associated access rules which define the authority of that user. When the user
`logs into the system a user interface object is created to perform operations on her behalf. We
`have been using the term User to mean this login domain.
`In addition the user has a personal domain (c.f. home directory) over which she has complete
`authority. The user can create sub domains to hold objects such as files and to which she can
`permit other user to have access i.e. the user is also a security administrator with unlimited
`SA_User_Scope and a SA_Target_Scop