Discretionary Access Control, part 2

Protection domains

See Schneider, chapter 7, 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, sections 7.3.{1,2,4}.

Revocation

See Schneider, chapter 7, section 7.3.5.

Exercises

1. Schneider, chapter 7, exercise 7.13

2. Schneider, chapter 7, exercise 7.18

3. Schneider, chapter 7, exercise 7.25