# Discretionary Access Control Recall that Lampson's *gold standard* identifies authorization, authentication, and audit as essential mechanisms for computer security. We begin studying authorization, which controls whether actions of principals are allowed, by considering access control. An *access control policy* specifies access rights, which regulate whether requests made by principals should be permitted or denied. In access control, we refine the notion of a principal to be one of a: - *user:* a human - *subject:* a process executing on behalf of a user - *object:* a piece of data or a resource. Why is that distinction important? Executing programs can be controlled; people can't. People can have different identities that they convey to programs. And the same program can be executed by different users. Determining which user a subject corresponds to is the problem of authentication, which we've already covered. The basic model we have in mind is that a subject attempts to access an object. The object is protected by a guard called a *reference monitor*. The principle of Complete Mediation says that reference monitor must check every access. The primary concerns of an access control system are the following: - **Prevent access:** in the absence of any privilege, ensure that the subject cannot access the object. The principle of Failsafe Defaults says that this should be the default. - **Determine access:** decide whether a subject has access, according to some policy, to take an action with an object. - **Grant access:** give a subject access to an object. The principle of Separation of Privilege says this should be fine-grained; don't grant access to many objects just to enable access to one. - **Revoke access:** remove a subject's access to an object. - **Audit access:** Determine which subjects can access an object, or which objects a subject can access. A *discretionary access control* (DAC) policy is a means of assigning access rights based on rules specified by users. The underlying philosophy in DAC is that subjects can determine who has access to their objects. DAC policies includes the file permissions model implemented by nearly all operating systems. In Unix, for example, a directory listing might yield "... `rwxr-xr-x ... file.txt`", meaning that the owner of file.txt may read, write, or execute it, and that other users may read or execute the file but not write it. The set of access rights in this example is {read, write, execute}, and the operating system mediates all requests to perform any of these actions. Users may change the permissions on files they own, making this a discretionary policy. A mechanism implementing a DAC policy must be able to answer the question: "Does subject S have right R for object O?" Abstractly, the information needed to answer this question can be represented as a mathematical relation D on subjects, objects, and rights: if (S,O,R) is in D, then S does have right R for object O; otherwise, S does not. More practically, the same information could also be represented as an *access control matrix* [Lampson 1971]. Each row of the matrix corresponds to a subject and each column to an object. Each cell of the matrix contains a set of rights. For example: <div align="center"> <table border="1"> <tr> <td></td> <td>file1</td> <td>file2</td> </tr> <tr> <td>Alice</td> <td>rwx</td> <td>r-x</td> </tr> <tr> <td>Bob</td> <td>r--</td> <td>rw-</td> </tr> </table> </div> Real systems typically store the information from this matrix either by columns or by rows. An implementation that stores by columns is commonly known as an *access control list* (ACL). File systems in Windows and Unix typically use such an implementation: each file is accompanied by a list of entries (s, rs), containing subjects s and their rights rs to that file. An implementation that stores by rows is commonly known as a *privilege list* or a *capability list*. Each subject maintains an unforgeable list of entries (o, rs) containing objects o and rights rs to that object. Android uses a privilege list: each app can be granted the right to access the network, GPS, phone, etc. Each implementation makes certain auditing concerns easier to address than others: - With ACLs, it's hard to audit what objects a subject can access, but easy to audit which subjects can access an object. - With privilege lists, it's easy to audit what objects a subject can access, but it's hard to audit which subjects can access an object, unless the system maintains a global map of capabilities. ### Commands The policy enforced by an access control system is rarely static. *Commands* are issued to change the policy. An access control system might provide commands to create and destroy objects, grant and revoke rights to objects, create and destroy subjects, create trust relationships between subjects, etc. A command can be specified as follows: ``` command C(args) requires: R ensures: E ``` `C` is the name of the command, `R` is a precondition that must hold for the command to be executed, and `E` is the effect the command has on the access control system. For example, the access control system for a file system might include include a right called `own` that indicates a subject owns an object. And this system might allow the owner of a file to grant the right to read the file to any other subject. That would be realized by the following command: ``` (* subject s grants read right for file f to subject q *) command grant-read-file(s,f,q) requires: (s,f,own) \in D ensures: D := D \union {(q,f,read)} ``` As another example, the system might support a command to create files, which grants the creator the `own`, `read`, and `write` commands: ``` (* subject s creates file f *) command create-file(s,f) requires: f does not already exist as an object in D ensures: D := D \union {(s,f,own), (s,f,read), (s,f,write)} ``` Some access control systems permit subjects other than the owner to *delegate* their rights to an object to another subject. For example, Alice might delegate her rights to read file `f` to Bob. The right to delegate rights to other principals is sometimes called the *copy right* or the *grant right*. A fine-grained access control system will associate a distinct copy right with every right. For example, the `read` right could be associated with the `delegate-read` right, the `execute` right could be associated with the `delegate-execute` right, etc. Here is a revised command for grant the right to read a file: ``` (* subject s delegates read right for file f to subject q *) command grant-read-file(s,f,q) requires: (s,f,delegate-read) \in D ensures: D := D \union {(q,f,read)} ``` Note that `q` will not be able to further delegate the `read` right to other principals, because the command does not grant `delegate-read` to `q`. ### Groups Students get access to a class because they are enrolled in it, not because of their own individual identities. Faculty get access to a fancy dining room on campus [would that were true...] because of their job status, not because of their own individual identities. In both cases, access is determined by being a member of a *group*. Group membership changes over time. So it's not wise to assign group-determined rights directly to individuals, because then administrators would need to redetermine rights anytime group memberships change. It's better to assign rights to a new kind of subject, a group, which is a named set of subjects. In ACLs, we can have a new kind of entry (g, rs), where g is group name. And separately, we can have a group list with entries (g, subjs), where g is the group name and subjs is set of subjects. For privilege lists, the implementation becomes a little more complex; we omit details here.