# Mandatory Access Control, part 2 ### Clark-Wilson The policies we have examined so far have been primarily concerned with maintaining secrecy of data. We are also interested in policies that ensure integrity of data. For instance, a bank is probably much more interested in ensuring that customers not be able to change account balances than it is in ensuring that account balances be kept secret. Although the latter is desirable, unauthorized data modification can usually cause much more harm to a business than inadvertent disclosure of information. In 1987, Clark and Wilson examined how businesses manage the integrity of their data in the "real world" and how such management might be incorporated into a computer system. In the commercial world, we need security policies that maintain the integrity of data. In this environment, illegal data modification occurs due to fraud and error. And there are two classical techniques to prevent fraud and error. The first technique is the principle of *Well-formed Transactions*. Users may not manipulate data arbitrarily, but only in constrained ways that preserve or establish its integrity. An example of this is double-entry bookkeeping. This involves making two sets of entries for everything that happens. Another example is the use of logs. Rather than erasing mistakes, the sequence of actions that reverses the mistake is performed and recorded on the log. A record of everything that has occurred is maintained. Using well-formed transactions makes it more difficult for someone to maliciously or inadvertently change data. Another technique to prevent fraud is the principle of *Separation of Duty*. Here, transactions are separated into subparts that must be done by independent parties. This works to maintain integrity as long as there is no collusion between agents working on different subparts. A typical transaction might look as follows: - A purchasing agent creates an order. The agent sends the order to both the supplier and the receiving agent. - The supplier ships the goods to the receiving department. The receiving clerk checks the goods that were received against the original order and updates the inventory records. - The supplier also sends an invoice to the accounting department. The accountant checks the invoice against both the original order and what the shipping clerk said was received. If they match, the accountant pays the bill. In this scenario, no one person can cause a problem that will go unnoticed. The separation of duty rule being employed here is: A person who can create or certify a well-formed transaction may not execute it. The question now becomes: How can we employ these commercial principles in computer systems? Clark and Wilson gave a set of rules for doing so. They postulate *trusted procedures* (TPs), which are programs that implement transactions. We summarize the Clark-Wilson rules as: 1. All subjects must be authenticated. 2. All TPs (and the operations they perform) must be logged—i.e., must be auditable. 3. All TPs must be approved by a central authority. 4. No data may be changed except by a TP. 5. All subjects must be cleared to perform particular TPs by a central authority. Note how these rules exemplify the gold standard: they address authentication, audit, and (the final three rules) authorization. Two other features of the Clark-Wilson model are: - Data managed by a system may be either *constrained*, meaning it is governed by the Clark-Wilson rules, or *unconstrained*, meaning that it is not governed by the rules. - A system may implement *integrity verification procedures* (IVPs), which test whether data is in a valid state. All TPs must guarantee the truth of IVPs. ### Role-based Access Control In the real world, security policies are dynamic. Access rights, whether discretionary or mandatory, need to change as the responsibilities of users change. This can make management of rights difficult. When a new user is authorized for a system, the appropriate rights for that user must be established. When a user changes job functions, some rights should be deleted, some maintained, and some added. Role-based access control (RBAC) addresses this problem by changing the underlying subject–object model. A *role* is a job function or title—i.e., a set of actions and responsibilities associated with a particular working activity. Now, instead of an access control policy being a relation on subjects, objects, and rights, a policy is a relation on roles, objects, and rights; this is called a *right assignment*. For example, the role "5430 TA" might be assigned the right to grade 5430 homeworks. Further, subjects are now assigned to roles; this is called a *role assignment*. Each subject may be assigned to many roles, and each role may be assigned to many subjects. Finally, roles are hierarchical. For example, the role "5430 Professor" should have all the rights that a "5430 TA" does, and more. Roles are similar to groups in Unix file system DAC. A group is a set of users with which some rights are associated. The same is true of a role. But in some implementations, a user is always a member of a group, whereas a subject may activate or deactivate the rights associated with any of the subject's roles. This enables finer-grained implementation of the Principle of Least Privilege. Subjects may login with most of their roles deactivated, and activate a role only when the rights associated with the role are necessary. Also, roles may be hierarchical, inheriting rights from other roles; that is not typically true of groups, even though it would be possible to implement.