User and Process Identity in Access Control

Access control mechanisms support two of the basic security objectives, confidentiality and integrity, through authentication of identity. This paper considers two schemes for access control, Access Control Lists (ACL) and Capabilities, and some hybrids. I propose a distinction between user identity and process identity as useful in understanding the best use of ACL and Capabilities. Evidence is presented from the literature that hybrid mechanisms best meet the security objectives of authentication when both user and process identity are considered.

    Access control has been called one of the principal security technologies [San96], supporting two of the basic security objectives, confidentiality and integrity [Pfl97, p5]. The most widely used access control mechanism in commercial operating systems is the access control list (ACL) [SS94, p 4], as used in Unix and other POSIX compliant systems [IEEE92]. An alternative mechanism is capabilities, introduced by Dennis and Horn [DH66]. One operating system that uses capabilities is EROS [SSF99].

    Comparisons of ACL and capabilities either, as in [SS94], trivialize the differences as being equivalent views of a Lampson access matrix [Lamp74], or claim some property that only one of the two satisfy [Boe84][Lam73][Har88]. This paper focuses the discussion by applying the mechanisms and the properties described in the literature to specific security objectives, looking at which mechanisms best satisfy the specific objectives.

    A distinction between user identity and process identity is defined and is shown to be useful in distinguishing the cases in which ACL or capability mechanisms work best. Some published hybrid mechanisms, which combine ACL and capabilities, are found to implement different access control mechanisms for user and process identities and satisfy the security objectives better than either ACL or capabilities alone.

    The next section presents definitions of terms used in describing access control mechanisms, the specific mechanisms being studied, and the security objectives that are being used in this paper to evaluate the different access control mechanisms. Each access control mechanism is then considered in terms of the major published arguments in favor and against it that relate to the specific security objectives. The conclusion proposes that what this paper calls hybrid mechanisms best meet all the security objectives.

    Access control   Mechanisms that mediate attempts by subjects to access resources in accord with security policies

    Subject   An active entity that can utilize resources to accomplish tasks. The literature does not always distinguish between processes as subject and the user under whose authority the process is being run.

    Resource   A passive object whose use is to be controlled by security policies, for example, files. Past literature has used the word object. This paper follows more recent usage that avoids confusion with the terminology of object-oriented programming (OOP). The data portion of an OOP object can be considered a resource.

    Access   Use of a resource. For example, a file is a resource, and various types of access to it are read, write, and execute. In OOP terms, any method of an object can be considered a type of access to the data that is controlled by that object.

    Access matrix   As defined in [Lam74], the access matrix is a table with a row for each subject and a column for each resource. Each cell specifies the types of access that the subject in the row is authorized to the resource in the column.

    Access control list (ACL)   The basis for an access control mechanism that stores for each resource a list of subjects that have authorized access to that resource, and possibly the types of access that are allowed.

    Capability   The basis for an access control mechanism that stores for each subject, reference to a resource and a list of types of access that subject is authorized to have to that resource. This definition follows the usage in EROS [SSF99] rather than the more limited definition in terms of rows of an access matrix as in [SS94].

    Hybrids   As used in this paper, access control mechanisms whose designs combine the use of ACLs and capabilities. The three hybrids discussed in this paper are SCAP [Kar88], ICAP [Gon89b], and mechanisms layered on EROS described in [SW00].

    *-property   A security policy introduced in [BLP75] that defines a restriction on flow of information in terms of an access matrix, stating that write access is permitted only if the security classification of the resource is greater than or equal to that of the subject. The *-property is supposed to ensure that a subject with authorization to an information resource cannot leak it to a subject that does not have such authorization.

    Confinement   The confinement problem was presented by Lampson [LAM73] as the problem of constraining an untrusted process that is used by a customer from leaking confidential input data to the owner of the process.

    Confused Deputy   The problem of preventing a subject that does not have authorized access to a resource from causing a subject that does have such access to perform the unauthorized access for it. The confused deputy problem was presented by Hardy [Har88] as an example of a problem that capabilities prevent but ACLs cannot. In his example a user asked the system compiler to write its output to a file in a directory that the compiler process had access to but the user did not. The user was able to supply a file name that caused the compiler to write over a sensitive system file.

    POSIX compliant operating systems [IEEE92], such as Unix and Linux implement an access control list mechanism in which subjects correspond to users of the system, resources are data objects such as files, and access types are Read, Write, and Execute. Processes can be subjects, but access control is based on the user who is considered the owner of the process.

    The *-property can be enforced by requiring that the access control lists only specify authorization that is satisfies the property. The enforcement is done by the mechanisms that are used to change the access matrix, referred to as mandatory access policies [SS94]. Mandatory access policies are independent of and compatible with the use of ACL for access control, and thus an ACL mechanism can achieve the security objectives implied by the *-property.

    Confinement is a more difficult problem, as it is presented in Lampson [Lam73]. The various mechanisms suggested by Lampson go beyond a subject’s access to resources to involve communication between processes across information channels. The details of his mechanisms are beyond the scope of this paper, other than to say that they are not expressible in terms of the access matrix.

    The Confused Deputy problem was originally presented by Hardy [Har88] as one that cannot be solved by an ACL mechanism. He characterizes the problem as that the user could designate a resource without having the authority to access it. The standard mechanism for avoiding such problems in Unix and Linux is through the use of setuid, which is a mechanism for a process to run using the security authorization of a user other than its owner. In this case the compiler would run as the user when it was writing to the file designated by that user, and so would have only the user’s authorization. Shapiro [SW00] claims that the setuid mechanism does not solve more complex versions of the confused deputy problem involving more than two subjects, but does not give any specific examples of such a case that demonstrates the setuid mechanism failing.

    Boebert [Boe84] claims that what he calls an “unmodified capability machine” cannot enforce the *-property. The argument is based on the claim that a capability carries with it the right to access a resource, and a subject with access to a capability can give it to another subject that should not have that right under the *-property. Kain and Landwehr [KL87] point out that Boebert’s arguments assume that capabilities are passed using the same rules as are used for passing of data. Lifting that assumption, they define a taxonomy of capability systems, some classifications of which can enforce the *-property. Shapiro [SW00] derives a formal proof that EROS can be used in such a way as to enforce the *-property. However the proof involves adding some features to EROS that would place the result in what this paper is calling a hybrid mechanism, discussed in the next section.

    Harrison, Ruzzo and Ullman [HRU76] present a formal proof of the undecidability of what they call the “safety” problem of determining whether a subject can acquire a specific access to a resource. This proof has been used to claim that capabilities cannot solve the confinement problem. Karger [Kar88] makes that claim and defines a hybrid mechanism to solve the confinement problem. Shapiro [SW00] points out that by using capabilities to restrict that passing of capabilities between objects separate from the control of read and write access to data, it is possible to formulate a capability system that falls within the set of restricted cases defined in [HRU76] in which the problem is decidable. [SW00] presents a formal verification of the confinement mechanism in EROS.

    EROS easily prevents the Confused Deputy problem through its principle of “no designation without authority” [SSF99][Har88] which means that it is not possible for a process to refer to a resource for which it does not already have a capability.

    Karger [Kar88] attempts to address the deficiencies that he perceives in the capability mechanism to enforce the *-property and to solve the confinement problem by designing a hybrid mechanism, called SCAP, that uses an ACL as an additional check on the authorization of a subject to use the access that it is granted by a capability.

    Gong [Gon89a][Gon89b] uses an inverse approach in ICAP. Where SCAP uses capabilities to support the ACL mechanism, ICAP uses ACL to support the implementation of capabilities. He claims similar results of handling *-property and the confinement problem, and that the mechanism is more suited in distributed network environments.

    Shapiro writes about EROS, which is usually described as a “pure” capability system [SSF99]. Yet in his formal verification of the EROS confinement mechanism [SW00] he introduces the notion of “weak” access restriction and the implementation of ACL at higher layers that result in some of the hybrid characteristics of SCAP and ICAP. He demonstrates enforcement of the *-property and the solution to the confinement problem, but with a result that best fits in what this paper is calling a hybrid scheme.

    There is much informal debate between proponents of ACL and of capability mechanisms about which one is “better”. Looking at the formal literature, as this paper does, reveals that there are problems that are not solved by either alone which are addressed by several mechanisms that combine features of both. An extensive formal analysis of the hybrid mechanisms is outside the scope of this paper. However, this paper will propose a distinction that can be used to distinguish where ACL and capability mechanisms each are of most use. Much of the literature refers to “subjects” without distinguishing between human users and software processes. Yet they are quite different. ACL’s require that all subjects be listed, and make it expensive to update the list of subjects, as that may require updating the access information for all resources. That is fine for subjects that are human users, but problematic if subjects are software objects or processes that are created, destroyed, and changed often and rapidly. On the other hand, capabilities are inherently low level and fine grained, suited for creation in an automated fashion in association with processes, but not easy to associate with people. A program can hold on to a data structure such as a capability; A person can more easily identify themselves to a system which has a record of their name and authorizations in an ACL.

    This paper will not attempt to prove the usefulness of the distinction between user and process identity in understanding access control mechanisms. It is raised as a possibility that can be further studied starting with the definitions and the mechanisms that have been presented.

[BLP75] D. E. Bell and L. J. LaPadula. "Secure Computer System: Unified Exposition and Multics Interpretations” Tech Report MTR-2997, MITRE Corp Bedford, MA, July 1975.

[Boe84] W. E. Boebert. "On the Inability of an Unmodified Capability Machine to Enforce the *-property" proceedings of the 7^th DoD/NBS Computer Security Conference, National Bureau of Standards, Gaithersburg, MD, USA, September 1984, pp 291-293.

 [DH66] J. B. Dennis and E. C. Van Horn. "Programming semantics for multiprogrammed computations" Communications of the ACM, 9(3), March 1966, pp 143-155.

[IEEE92] IEEE Portable Applications Standards Committee, “P1003.13: Information Technology – Standardized Applications Environment Profile – POSIX Realtime Application Support (AEP) (Draft 5), IEEE, February 92.

[Gon89a] Li Gong. "On Security in Capability-Based Systems" ACM Operating Systems Review, 23(2), April 1989, pp 56-60.

[Gon89b] Li Gong. "A Secure Identity-Based Capability System" IEEE Symposium on Security and Privacy, May 1989, pp 56-64.

[Har88] Norm Hardy. "The Confused Deputy: or why capabilities might have been invented " ACM Operating Systems Review, 22(4), October 1988, pp 36-38.

 [HRU76] M. Harrison, W. Ruzzo, and J. Ullman. "Protection in operating systems" Communications of the ACM, 19(8), August 1976, pp 461-471.

[Kar88] Paul A. Karger. "Implementing Commercial Data Integrity with Secure Capabilities" IEEE Symposium on Security and Privacy, April 1988, pp 130-139.

[KL87] R. Y. Kain and C. E. Landwehr. "On Access Checking in Capability-Based Systems" IEEE Transactions on Software Engineering, Vol SE13, No. 2, February 1987, pp 202-207.

 [Lam73] Butler W. Lampson. "A Note on the Confinement Problem" Communications of the ACM, 16(10), October 1973, pp 613-615.

[Lam74] Butler W. Lampson. "Protection" ACM Operating Systems Review, 8(1), January 1974, pp 18-24.

[Pfl97] Charles P. Pfleeger. Security in Computing, Second Edition, Prentice Hall PTR, 1997.

[San96] Ravi Sandhu. "Access Control: The Neglected Frontier" proceedings First Australasian Conference on Information Security and Privacy, Woolongong, Australia, June 1996.

[SS94] Ravi Sandhu and P. Samarati. "Access Control: Principles and Practice" IEEE Computer, Vol 32, No. 9, September 1994, pp 40-48.

 [SSF99] Jonathan S. Shapiro, Jonathan M. Smith and David J. Farber. "EROS: a fast capability system" proceedings of the 17^th ACM Symposium on Operating System Principles (SOSP '99), December 12-15 1999.

[SW00] Jonathan S. Shapiro and Sam Weber. "Verifying the EROS Confinement Mechanism" IEEE Symposium on Security and Privacy, May 2000, pp 166-176.