# Discretionary Access Control, part 2
## Protection domains
See [Schneider, chapter 7][S7], sections 7.1.1 and 7.1.2.
## 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.
## Cryptographic capabilities
The discussion of privilege/capability lists suggested that a
trusted access control system manage storage of the lists. In a
distributed system, it would instead be possible to have untrusted
subjects manage the storage of those lists. Alice could keep track of
the capabilities issued to her, Bob of those to him, and so forth. But
now the *authenticity* of those capabilities must be ensured: we would
not want subjects to be able to manufacture capabilities never issued to
them by the access control system.
Digital signatures provide a mechanism to implement capabilities in this
distributed setting. To issue a right `r` to a subject named `S` for an
object named `O`, the access control system can construct a capability
`cap`, where `cap=(S,O,r)`, and sign that capability, producing a
signature `s`, where `s=Sign(cap; k_AC)` and where `k_AC` is a private
signing key for the access control system. The pair `(cap,s)` can be
given by the access control system to the subject. Whenever the subject
wishes access, it presents `(cap,s)` back to the access control system,
which verifies the signature and the rights contained in the capability.
This scheme can be modified support delegation:
- The subject's name could be omitted from the capability. This would
enable subjects to easily delegate capabilities, simply by giving
another subject a copy of the capability.
- Instead of using a single key pair, many key pairs could be
employed. For example, there could be one key pair `(K_O, k_O)` per
object `O` in the system. The access control system could delegate
management of access control for `O` to a subject `S` by giving
`k_O` to `S`. Any component that needed to verify capabilities for
`O` would need to know `K_O`.
Revocation, however, now becomes a problem, much like it did for digital
certificates. It might not be possible to delete capabilities once they
have been issued. So the access control system might need to include
validity intervals (so that capabilities expire), or maintain revocation
lists (which must be consulted by the reference monitor).
Moreover, these capabilities are expensive. Creating keys and verifying
digital signatures both take time, and storing the signature takes
space.
## Other implementations of capabilities
Tagged memory, protected address spaces,
and type safety are other means to implement capabilities.
See [Schneider, chapter 7][S7], sections 7.3.{1,2,4}.
## Revocation
See [Schneider, chapter 7][S7], section 7.3.5.
## Exercises
1. [Schneider, chapter 7][S7], exercise 7.13
2. [Schneider, chapter 7][S7], exercise 7.18
3. [Schneider, chapter 7][S7], exercise 7.25
[S7]: http://www.cs.cornell.edu/fbs/publications/chptr.DAC.pdf