Lesson 12.4: Access Control Models

01 Introduction

Lesson 12.3 presented the authorization's concepts and the four models that the systems use: the discretionary access control (the DAC: the owners' discretion), the mandatory access control (the MAC: the system's policy), the role-based access control (the RBAC: the roles), and the attribute-based access control (the ABAC: the attributes). This lesson presents the models' formal foundations: the mathematical's frameworks that the models are based on, and the properties that the formalization lets the designers prove.

The formal access control models are the authorization's theory. Their purpose is the precise specification of the policies and the provable properties of the policies: a formal model defines the policy's rules in the mathematical's terms (the sets, the relations, the functions, the state machines), and it lets the designers ask the questions that the informal's specifications cannot answer. The most important question is the safety problem: given a policy and a set of the operations, can the system determine whether a particular subject can ever obtain a particular permission? The safety problem's answer determines the policy's enforcement's complexity, and its general's undecidability (the Harrison-Ruzzo-Ullman result) is one of the formal models' foundational results.

The formal models' history begins with the access control matrix (the Lampson paper, 1971) and its formalization by Harrison, Ruzzo, and Ullman (the HRU model, 1976). The HRU model's result — the safety problem's undecidability for the general's access control matrix — motivated the search for the restricted models whose safety could be decided. The Bell-LaPadula model (1973, the MITRE report; 1976, the unified exposition) was the first of the restricted models: it specifies the confidentiality's policy through the security levels and the two rules (the simple security property and the *-property), and its safety is decidable. The Biba model (1977) is the confidentiality's model's dual: it specifies the integrity's policy through the integrity levels and the two rules (the simple integrity axiom and the *-integrity axiom). The Clark-Wilson model (1987) is the commercial's integrity model: it specifies the integrity through the well-formed transactions and the separation of duties, and its design's motivation is the commercial's accounting and the banking's systems. The Take-Grant model (1976) is the graph-based model: it represents the authorization's state as a directed graph and specifies the operations (the take, the grant, the create, the remove) that transform the graph. The RBAC's formalization (the Sandhu et al. paper, 1996) is the role-based model's precise specification: it defines the RBAC's components (the users, the roles, the permissions, the sessions, the constraints) and the four variants (the RBAC0 through the RBAC3). The ABAC's framework (the NIST SP 800-162, 2014) is the attribute-based model's specification: it defines the attributes, the policies, and the reference architecture's components.

This lesson presents the formal access control models. It presents the access control matrix and the HRU model's safety problem and its result. It presents the Bell-LaPadula model (the confidentiality's rules and the security levels) and the Biba model (the integrity's rules and the integrity levels). It presents the Clark-Wilson model (the well-formed transactions, the constrained data items, and the separation of duties) and the Take-Grant model (the graph-based state and the transformation's rules). It presents the RBAC's formalization (the RBAC0 through the RBAC3) and the ABAC's framework (the NIST SP 800-162). It compares the models (the confidentiality versus the integrity, the mandatory versus the discretionary, the static versus the dynamic) and shows how they appear in the real systems (the SELinux's type enforcement, the TrustedBSD's MAC framework, the databases' Clark-Wilson's implementations, the cloud's RBAC and ABAC). It closes with the formal models' role in the modern systems' design and the lesson's synthesis.

Prerequisites

This lesson builds on Lessons 12.1, 12.2, and 12.3. The security's goals (the CIA triad), the AAA model, the reference monitor, and the Saltzer and Schroeder principles are assumed (Lesson 12.1). The authentication's mechanisms are assumed (Lesson 12.2). The authorization's concepts (the subjects, the objects, the operations, the permissions), the access control matrix, the four models (the DAC, the MAC, the RBAC, the ABAC), and the mechanisms (the permissions' bits, the ACLs, the capabilities, the security labels) are assumed (Lesson 12.3). The lesson is the formal models' presentation, and it uses the mathematical's notation (the sets, the relations, the functions, the state machines) at the level that the paper's definitions require. No prior mathematical's knowledge beyond the basic set theory and the relations is assumed; the definitions are explained as they are introduced. Familiarity with the Linux command line from Lesson 2.2 is helpful, since the interactive activity uses the SELinux's tools and the system's authorization's interfaces.

02 Learning objectives

By the end of this lesson you will be able to

Explain the role of the formal access control models and describe the safety problem.
Describe the access control matrix's formalization (the Harrison-Ruzzo-Ullman model) and explain the safety problem's undecidability result.
Describe the Bell-LaPadula model (the security levels, the simple security property, and the *-property) and explain how it enforces the confidentiality.
Describe the Biba model (the integrity levels, the simple integrity axiom, and the *-integrity axiom) and explain how it enforces the integrity.
Describe the Clark-Wilson model (the constrained data items, the well-formed transactions, and the separation of duties) and the Take-Grant model (the graph-based state and the transformation's rules).
Describe the RBAC's formalization (the RBAC0 through the RBAC3) and the ABAC's framework (the NIST SP 800-162), and compare the formal models' properties and their applications.

This lesson contributes to U12.4 and U12.5, and to course learning outcomes CLO1, CLO7, and CLO8.

03 Required reading

Operating System Concepts — Chapter 17, Protection, Sections 17.1–17.5. The standard treatment of the protection's goals, the access control matrix, the protection's models, and the formal models' role.
OSTEP — the Security chapters, particularly the discussion of the access control and the protection's models. OSTEP's treatment of the access control matrix and the capabilities is the clearest available account of the matrix's formalization, and it is the basis for the worked example in this lesson.
Tanenbaum & Bos — Modern Operating Systems, Chapter 9, Security, Sections 9.7–9.9. A complementary treatment that develops the protection's models from first principles.
Lampson, B. W. — Protection. Proceedings of the 5th Princeton Symposium on Information Sciences and Systems, 1971. The paper that introduced the access control matrix and the capability's concept, and it is the formal models' historical foundation.
Harrison, M. A., Ruzzo, W. L., & Ullman, J. D. — Protection in Operating Systems. Communications of the ACM, 1976. The paper that formalized the access control matrix (the HRU model) and proved the safety problem's undecidability.
Bell, D. E., & LaPadula, L. J. — Secure Computer System: Unified Exposition and Multics Interpretation. MITRE Technical Report, 1976. The paper that introduced the Bell-LaPadula model, and it is the mandatory access control's classical confidentiality model.
Biba, K. J. — Integrity Considerations in Secure Computer Systems. MITRE Technical Report, 1977. The paper that introduced the Biba model, the integrity's counterpart of the Bell-LaPadula model.
Clark, D. D., & Wilson, D. R. — A Comparison of Commercial and Military Computer Security Policies. IEEE Symposium on Security and Privacy, 1987. The paper that introduced the Clark-Wilson model, the commercial's integrity model.
Sandhu, R. S., Coyne, E. J., Feinstein, H. L., & Youman, C. E. — Role-Based Access Control Models. IEEE Computer, 1996. The paper that formalized the role-based access control and its four variants (the RBAC0 through the RBAC3).
Hu, V. C., Ferraiolo, D. F., & Kuhn, D. R. — Guide to Attribute Based Access Control (ABAC) Definition and Considerations. NIST SP 800-162, 2014. The NIST's guide to the attribute-based access control and its framework.
Bishop, M. — Computer Security: Art and Science, 2nd ed. Addison-Wesley, 2019. The formal treatment of the access control models, including the Bell-LaPadula, the Biba, the Clark-Wilson, and the HRU models.
Linux man pages: man 8 selinux, man 8 semanage, man 8 chcon, man 5 selinux_config (if available), man 8 aa-status, man 5 apparmor.d, man 7 capabilities, man 8 setcap, man 1 getenforce, man 1 sestatus, man 8 seinfo (if available).

Reading strategy

Read the Silberschatz chapter first. It presents the protection's goals, the access control matrix, and the formal models' role, and it introduces the Bell-LaPadula and the Biba models at the level that the lesson's core content requires. Then read the Lampson paper for the access control matrix's original presentation, and the Harrison-Ruzzo-Ullman paper for the safety problem's formalization and its undecidability result. The Bell-LaPadula and the Biba papers are the two models' primary sources, and they are worth reading for the models' precise definitions (the security levels, the simple security property, the *-property, the integrity levels, the simple integrity axiom, and the *-integrity axiom). The Clark-Wilson paper is the commercial's integrity model, and it is worth reading for the well-formed transactions' and the separation of duties' definitions. The Sandhu et al. and the NIST SP 800-162 papers are the RBAC's and the ABAC's formalizations, and they are worth reading for the models' precise components and their applications. Finally, the Bishop book is the comprehensive reference, and it is worth consulting for the models' formal proofs and their relationships. Pay particular attention to the distinction between the model (the policy's precise specification: the subjects, the objects, the permissions, and the rules) and the mechanism (the policy's enforcement: the reference monitor, the kernel's checks, the application's gates). The formal models are the policies' specifications, and the mechanisms are the policies' implementations; the two are the authorization's design's independent dimensions, and the formal models' value is the precise reasoning that the specifications allow.

04 Core content

4.1 The role of the formal access control models

The formal access control models are the mathematical's frameworks that specify the authorization's policies precisely. Their purpose is threefold:

The precise specification. The formal model defines the policy's rules in the mathematical's terms (the sets, the relations, the functions, the state machines), so the policy's meaning is the unambiguous. The informal's specifications (the prose's policies, the administrators' guidelines) are the ambiguous, and their ambiguity is the security's bug's source: the two administrators can interpret the same policy differently, and the implementation can enforce the interpretation that the designers did not intend. The formal model removes the ambiguity: the policy's rules are the mathematical's statements, and their meaning is the precise.
The provable properties. The formal model lets the designers ask the questions that the informal's specifications cannot answer: is the policy safe (can a subject obtain a permission that the policy did not intend to grant)? Is the policy consistent (are the rules' conflicts resolved)? Is the policy complete (does it cover the every access)? The properties' proofs are the formal models' central value: a policy whose safety is proved is the policy whose enforcement's correctness can be established, and the proof is the design's evidence.
The design's comparison. The formal model lets the designers compare the policies' properties, their expressiveness, and their enforcement's complexity. The models' comparison is the authorization's design's guidance: the Bell-LaPadula's confidentiality's enforcement's cost, the Biba's integrity's enforcement's cost, the Clark-Wilson's commercial's integrity's enforcement's cost, the RBAC's manageability's properties, the ABAC's expressiveness's properties. The comparison's result is the design's choice: the model that matches the application's requirements and its enforcement's constraints.

The formal models' central question is the safety problem: given a policy (the initial state's permissions) and a set of the operations (the state's transformations), can the system determine whether a particular subject can ever obtain a particular permission? The safety problem's answer determines the policy's enforcement's complexity: a policy whose safety is decidable can be enforced with the precise guarantees, and a policy whose safety is undecidable cannot. The safety problem's formal treatment is the Harrison-Ruzzo-Ullman model's contribution, and its undecidability result is one of the formal models' foundational results.

4.2 The Harrison-Ruzzo-Ullman (HRU) model

The Harrison-Ruzzo-Ullman (HRU) model (1976) is the access control matrix's formalization. The model's components are:

The subjects and the objects. The model's sets: the subjects (the active entities) and the objects (the passive entities). A subject can also be an object (a process can be the target of the operations), and the model treats the subjects as the objects' special's case.
The access rights. The model's set: the rights (the read, the write, the execute, the own, the grant, ...), the permissions that the subjects can hold on the objects.
The access control matrix. The model's state: the matrix whose rows are the subjects, whose columns are the objects, and whose entries are the subjects' rights on the objects.
The commands. The model's operations: the commands that transform the state (the matrix). Each command has the condition (the precondition: the rights the subject must hold to execute the command) and the primitive operations (the postcondition: the rights the command enters and deletes in the matrix). The primitive operations are the enter (the right's addition to the matrix's entry) and the delete (the right's removal from the matrix's entry).

The model's state is the matrix, and the model's operations are the commands that transform the state. The model's example commands are:

The create's command. The subject creates a new object, and the command enters the subject's own right in the new object's entry.
The grant's command. The subject s grants the right r on the object o to the subject s': the command's condition is the subject's own right on the object (or the grant right), and the command's primitive operation enters the right r in the matrix's [s', o] entry.
The revoke's command. The subject s revokes the right r on the object o from the subject s': the command's condition is the subject's own right on the object, and the command's primitive operation deletes the right r from the matrix's [s', o] entry.

The HRU model's central result is the safety problem's undecidability: for the general's access control matrix (the arbitrary commands with the arbitrary conditions and the primitive operations), the problem of determining whether a particular subject can ever obtain a particular right is undecidable. The result's proof is the reduction from the Turing machine's halting problem: the HRU model's commands can simulate the Turing machine's operations, so the safety problem's decision would decide the halting problem, which is the undecidable.

The HRU model's undecidability result is the formal models' motivation's turning point: the general's access control matrix's safety cannot be decided, so the designers must restrict the model to obtain the decidable's safety. The restricted models are the Bell-LaPadula, the Biba, the Clark-Wilson, the Take-Grant, and the RBAC: each restricts the commands or the state, so the safety problem becomes the decidable, and each provides the policy's expressiveness within the restriction. The observation is the formal models' design's central trade-off: the expressiveness versus the decidability, and the models are the different balances.

4.3 The Bell-LaPadula model

The Bell-LaPadula model (1973, 1976) is the mandatory access control's confidentiality model. The model's components are:

The security levels. The model's classification: the security levels are the ordered (the unclassified, the confidential, the secret, the top secret), and the objects and the subjects are assigned the levels. The levels' order is the partial order (the lattice's structure), and the model's rules use the order's comparison (dominates: the level that is the higher in the order dominates the lower).
The categories (the compartments). The model's additional classification: the categories are the sets (the project's names, the countries, the departments), and the subject's and the object's labels are the pairs (the level, the categories' set). The category's presence's combination with the level's order gives the model's label's lattice: the label l1 dominates the label l2 if the level of l1 is the higher or the equal and the categories of l1 include the categories of l2.
The state. The model's state: the set of the current's accesses (the subject's current's level, the object's current's level, the current's access mode: the read, the write, the append, the execute).

The model's policy is the two rules:

The simple security property (the "no read up"): A subject at the level l_s can read an object at the level l_o only if l_s dominates l_o (the subject's level is the higher or the equal). The rule prevents the subject from reading the objects with the higher classification, so the subject cannot learn the secrets above their clearance. The rule's name ("the no read up") reflects its effect: the subject cannot read the objects above their level.
The *-property (the star property, the "no write down"): A subject at the level l_s can write to an object at the level l_o only if l_o dominates l_s (the object's level is the higher or the equal). The rule prevents the subject from writing to the objects with the lower classification, so the subject cannot leak the secrets to the objects below their level. The rule's name ("the no write down") reflects its effect: the subject cannot write to the objects below their level.

The two rules' combination is the model's confidentiality's enforcement: the no read up prevents the subject from reading the secrets above their clearance, and the no write down prevents the subject from leaking the secrets to the objects below their level. The two rules together enforce the information's flow's one-direction: the information can flow from the lower classifications to the higher, but not the reverse.

The model's example: the subject alice has the level secret and the categories {nato}. The object report1 has the level confidential and the categories {nato}, and the object report2 has the level top secret and the categories {nato}. The simple security property allows alice to read report1 (the secret dominates the confidential and the categories match) and denies alice the read on report2 (the secret does not dominate the top secret). The *-property allows alice to write to report2 (the top secret dominates the secret) and denies alice the write on report1 (the confidential does not dominate the secret).

The model's variant is the Bell-LaPadula with the strong *-property: the subject can write to the object at the level l_o only if the subject's level equals the object's (not merely dominates). The strong's variant is more restrictive, and it prevents the subject from writing the secrets to the higher-level objects' mixed's contents.

The model's advantages are its confidentiality's enforcement (the two rules prevent the secrets' leaks) and its provable properties (the model's safety is decidable: the model's state's transitions preserve the two rules, and the safety's proof is the model's central's result). Its disadvantages are its rigidity (the model's rules cannot express the exceptions) and its incompleteness (the model addresses the confidentiality, not the integrity or the availability). The model's implementations are the Multics's system (the model's origin), the SELinux's MLS (the Multi-Level Security), and the TrustedBSD's MAC's MLS's module.

confidentiality: the no read up (the secrets' reading's prevention) and the no write down (the secrets' leaking's prevention). The Biba (the right) protects the integrity: the no read down (the corrupted data's reading's prevention) and the no write up (the corrupted data's propagation's prevention).

Figure 12.4 — The Bell-LaPadula and the Biba models. The Bell-LaPadula model (the left) protects the confidentiality through the two rules: the simple security property (the no read up: the subject cannot read the objects above their level) and the *-property (the no write down: the subject cannot write to the objects below their level). The Biba model (the right) protects the integrity through the two dual rules: the simple integrity axiom (the no read down: the subject cannot read the objects below their level) and the *-integrity axiom (the no write up: the subject cannot write to the objects above their level). The two models' rules' symmetry reflects the confidentiality and the integrity's dual requirements: the confidentiality's information flows from the lower to the higher classifications, and the integrity's information flows from the higher to the lower integrity levels.

4.4 The Biba model

The Biba model (1977) is the integrity's model, the Bell-LaPadula model's dual. The model's components are:

The integrity levels. The model's classification: the integrity levels are the ordered (the untrusted, the low, the medium, the high), and the objects and the subjects are assigned the levels. The levels' order is the integrity's measure: a higher level means the more trusted (the more reliable, the more accurate).
The categories (the compartments). The model's additional classification, as in the Bell-LaPadula: the categories' sets and the levels' order combine into the label's lattice.
The state. The model's state: the set of the current's accesses.

The model's policy is the two rules, the Bell-LaPadula's rules' dual:

The simple integrity axiom (the "no read down"): A subject at the integrity level l_s can read an object at the level l_o only if l_o dominates l_s (the object's level is the higher or the equal). The rule prevents the subject from reading the objects with the lower integrity, so the subject's data cannot be contaminated by the less trusted sources.
The *-integrity axiom (the "no write up"): A subject at the integrity level l_s can write to an object at the level l_o only if l_s dominates l_o (the subject's level is the higher or the equal). The rule prevents the subject from writing to the objects with the higher integrity, so the corrupted data cannot flow to the more trusted objects.

The two rules' combination is the model's integrity's enforcement: the no read down prevents the subject from reading the less trusted data, and the no write up prevents the subject from writing to the more trusted objects. The two rules together enforce the information's flow's one-direction: the information can flow from the higher integrity to the lower, but not the reverse. The observation is the reason the Biba is the Bell-LaPadula's dual: the Bell-LaPadula protects the confidentiality (the secrets cannot flow down), and the Biba protects the integrity (the corruption cannot flow up).

The model's variants are:

The strict integrity policy. The subject reads only the objects at or above their level (the no read down) and writes only the objects at or below their level (the no write up). The variant is the model's standard formulation.
The low-watermark policy. The subject's integrity level is the minimum of the subject's level and the levels of the objects the subject has read. The variant's dynamic's character: the subject's level drops when the subject reads the lower-integrity's data, so the subject cannot later write to the higher-integrity's objects. The variant's cost is the subject's integrity's degradation: the subject's level is the monotone's decreasing, and the subject's utility declines with the reads.
The ring policy. The subject reads any object (the no read down's relaxation), and writes only the objects at or below their level (the no write up). The variant's rationale: the read's contamination is the subject's concern, not the system's, and the write's protection is the system's concern. The variant is the less restrictive and the more practical.

The model's advantages are its integrity's enforcement (the two rules prevent the corrupted data's propagation) and its dual's symmetry (the Bell-LaPadula's rules' dual, so the two models' analyses are the parallel). Its disadvantages are its rigidity (the rules cannot express the exceptions) and its availability's cost (the rules' restrictions can interfere with the legitimate's work). The model's implementations are the TrustedBSD's MAC's Biba's module and the SELinux's integrity's extensions.

4.5 The Clark-Wilson model

The Clark-Wilson model (1987) is the commercial's integrity model. The model's motivation is the commercial's requirements: the integrity of the commercial's data (the accounting's records, the banking's transactions) and the separation of duties (the organizational's control). The model's components are:

The constrained data items (CDIs): The data items that the model's integrity protects: the accounting's records, the banking's balances, the inventory's levels. The CDIs' integrity is the model's purpose, and their modification is the model's concern.
The unconstrained data items (UDIs): The data items that the model's integrity does not protect: the user's input, the external's data. The UDIs are the untrusted's data, and their transformation into the CDIs is the model's concern.
The integrity verification procedures (IVPs): The procedures that verify the CDIs' integrity: the checks that the CDIs satisfy the model's integrity constraints (the accounting's balance's consistency, the inventory's levels' validity). The IVPs are the model's verification's component.
The transformation procedures (TPs): The procedures that modify the CDIs: the banking's transactions, the accounting's entries, the inventory's updates. The TPs are the model's modification's component, and their design is the model's central concern: the TPs are the well-formed transactions that preserve the CDIs' integrity.

The model's policy is the set of the certification and the enforcement rules:

The certification rules (the C1–C5). The rules that the security officer (the administrator) applies to verify the model's design: the IVPs must verify the CDIs' integrity (the C1), the TPs must be certified for the CDIs they modify (the C2), the access's rules must enforce the separation of duties (the C3), the TPs' log must record the modifications (the C4), and the TPs that accept the UDIs must transform them into the CDIs (or reject them) (the C5).
The enforcement rules (the E1–E4). The rules that the system enforces: the system must enforce the IVPs (the E1), the system must enforce the TPs' certification (the E2), the system must enforce the separation of duties (the E3), and the system must enforce the TPs' log (the E4).

The model's central concept is the well-formed transaction: the TP that preserves the CDIs' integrity. The well-formed transaction's properties are the atomicity (the transaction is the all-or-nothing), the consistency (the transaction preserves the CDIs' integrity constraints), the isolation (the transaction's intermediate states are not visible), and the durability (the transaction's effects survive the system's failures). The properties are the classical database's ACID's properties, and the observation is the reason the Clark-Wilson model is the database's and the transaction's systems' integrity's model: the well-formed transactions are the database's transactions, and the CDIs are the database's records.

The model's other central concept is the separation of duties: the model's requirement that the critical operations require the multiple subjects' involvement. The model's separation of duties is enforced through the TPs' certification: the TP's design requires the two subjects' roles (the requester and the approver, the teller and the auditor), and the system's enforcement (the E3) ensures the two subjects are the distinct.

The model's advantages are its commercial's alignment (the model's concepts — the CDIs, the TPs, the separation of duties — are the commercial's concepts) and its integrity's enforcement (the well-formed transactions preserve the CDIs' integrity). Its disadvantages are its complexity (the model's rules and the certification's requirements are the burdensome) and its scope (the model addresses the integrity, not the confidentiality or the availability). The model's implementations are the commercial's database's systems (the accounting's software, the banking's systems, the ERP's systems), and its concepts (the well-formed transactions, the separation of duties) are the modern database's and the enterprise's software's standard.

4.6 The Take-Grant model

The Take-Grant model (1976) is the graph-based access control model. The model's state is the directed graph: the nodes are the subjects and the objects, and the edges are the rights (the read, the write, the take, the grant). The model's operations are the transformation's rules:

The take's rule. The subject s that has the take right on the subject s' can take the rights that s' has on the object o. The rule's effect: the take right's holder can acquire the other's rights.
The grant's rule. The subject s that has the grant right on the subject s' can grant the rights that s has on the object o to s'. The rule's effect: the grant right's holder can transfer the rights.
The create's rule. The subject s can create the new node (the subject or the object) and the new edges (the rights) from s to the new node.
The remove's rule. The subject s can remove the edge (the right) from the node x to the node y if s has the take or the grant right on x.

The model's purpose is the sharing's analysis: the model's rules determine how the rights can be propagated through the graph, and the model's questions are the sharing's questions (can the subject s share the rights with the subject s'?) and the stealing's questions (can the subject s acquire the rights without the owner's consent?). The model's answers are the graph's properties: the sharing is possible if the graph has the specific tg-path (the path with the take and the grant edges), and the stealing is possible if the graph has the specific island (the subgraph's structure).

The Take-Grant model's advantages are its graph's intuitiveness (the model's state and the operations are the visual and the natural) and its decidable's questions (the model's sharing's and the stealing's questions are the decidable, and the answers are the graph's polynomial's properties). Its disadvantages are its limited's expressiveness (the model's rights are the few, and the model's policies are the simple) and its scope (the model addresses the rights' propagation, not the confidentiality or the integrity). The model's value is the theoretical's: it is the formal models' demonstration that the restricted's access control's questions can be the decidable, and its graph's concepts (the take and the grant rights, the tg-path, the island) are the access control's theory's classical's concepts.

4.7 The RBAC's formalization

The RBAC's formalization (the Sandhu et al. paper, 1996) specifies the role-based access control's components and its four variants. The formalization's components are:

The users (U), the roles (R), the permissions (P), and the sessions (S). The model's sets.
The user's assignment (UA ⊆ U × R). The relation that assigns the users to the roles. The relation's semantics: the user has the role's permissions when the role is assigned.
The permission's assignment (PA ⊆ P × R). The relation that assigns the permissions to the roles. The relation's semantics: the role has the permissions when the role is assigned.
The session's roles (the function session_roles: S → 2^R). The function that maps the session to the roles the session activates. The session's roles are the subset of the user's roles (the user's assignment's roles).
The permission's function (the function session_permissions: S → 2^P). The function that maps the session to the permissions the session has. The session's permissions are the union of the roles' permissions (the permission's assignment's roles).

The model's four variants are:

RBAC0 (the base model)

The model's components: the users, the roles, the permissions, the sessions, the user's assignment, the permission's assignment, and the session's functions. The RBAC0 is the model's minimal's specification, and its properties are the consistency (the user's permissions are the union of the session's roles' permissions) and the least privilege (the session's roles are the subset of the user's roles).

RBAC1 (the hierarchical model)

The RBAC0 plus the role's hierarchy (the relation RH ⊆ R × R: the role r1 inherits the role r2 if the pair (r1, r2) is in the relation). The hierarchy's semantics: the senior role's members inherit the junior role's permissions. The hierarchy's properties: the transitivity (the inheritance is the transitive), the reflexivity (the role inherits itself), and the anti-symmetry (the hierarchy is the partial order).

RBAC2 (the constrained model)

The RBAC0 plus the constraints. The constraints are the rules that restrict the model's assignments and the sessions' activations:

The mutually exclusive roles. The roles that cannot be assigned to the same user (the separation of duties: the requester and the approver, the teller and the auditor).
The cardinality's constraints. The maximum number of the users per role (the role's capacity) or the maximum number of the roles per user (the user's capacity).
The prerequisite's constraints. The role's assignment's requirement: the user can be assigned the role r1 only if the user is already assigned the role r2.

RBAC3 (the unified model)

The RBAC1 plus the RBAC2: the hierarchy and the constraints' combination. The RBAC3 is the model's full's specification, and its properties are the hierarchy's and the constraints'.

The model's advantages are its formal's clarity (the model's components and the relations are the precise, so the RBAC's properties can be the analyzed) and its practical's alignment (the model's components — the users, the roles, the permissions, the sessions, the constraints — are the real systems' components, so the model is the implementable). Its disadvantages are its role's explosion (the model's roles are the many in the large's systems, and the model's management is the complex) and its static's nature (the model's roles are the assigned, not the computed from the context). The model's implementations are the many: the applications' RBAC's systems, the cloud's IAM's roles, the operating systems' RBAC's extensions.

4.8 The ABAC's framework

The ABAC's framework (the NIST SP 800-162, 2014) specifies the attribute-based access control's components and its reference architecture. The framework's components are:

The attributes. The properties of the subjects, the objects, the operations, and the environment. The attributes are the name-value pairs (the subject's department = "finance", the object's classification = "confidential", the operation's type = "read", the environment's time = "09:00"), and their sources are the authoritative's systems (the HR's database, the asset's management's system, the environment's sensors).
The policies. The rules that determine the access on the basis of the attributes' values. The policies are the boolean's expressions (the simple: the subject's department = the object's department) or the rule-based's expressions (the complex: the XACML's rules with the conditions, the obligations, and the effects).
The architecture. The framework's components and their interactions: the policy enforcement point (the PEP: the component that intercepts the access's requests and enforces the decisions), the policy decision point (the PDP: the component that evaluates the policies and makes the decisions), the policy information point (the PIP: the component that provides the attributes' values), the policy administration point (the PAP: the component that manages the policies), and the context handler (the component that coordinates the PIP's and the PDP's requests).

The framework's flow: the subject's access's request reaches the PEP, which forwards the request's context (the subject, the object, the operation, the environment) to the PDP. The PDP evaluates the policies against the context, and it may query the PIP for the additional attributes' values. The PDP returns the decision (the permit, the deny, the indeterminate) to the PEP, which enforces it (the access's grant or denial, and the obligations' execution).

The framework's advantages are its expressiveness (the attributes and the rules can express the fine-grained and the context-dependent's policies) and its flexibility (the policies can be changed without the subjects' and the objects' changes). Its disadvantages are its complexity (the policies' rules and their interactions are the hard to the understand, and the policies' verification is the difficult) and its attributes' management (the attributes' sources, their updates, and their trustworthiness are the burdensome). The framework's implementations are the modern's systems' emerging: the cloud's zero-trust's architectures, the software-defined's perimeter's systems, the XACML's policy engines, and the applications' attribute-based's systems.

4.9 The models' comparison

The formal access control models' comparison:

The formal access control models' comparison
Model	The policy's focus	The key's concept	The safety	The typical's application
HRU	The matrix's general	The access control matrix, the commands	Undecidable	The theoretical's foundation
Bell-LaPadula	The confidentiality	The security levels, the no read up, the no write down	Decidable	The MLS's systems (SELinux's MLS, Multics)
Biba	The integrity	The integrity levels, the no read down, the no write up	Decidable	The integrity's systems (TrustedBSD's MAC, the database's integrity)
Clark-Wilson	The commercial's integrity	The CDIs, the TPs, the separation of duties	Decidable	The commercial's systems (the databases, the accounting's software)
Take-Grant	The rights' propagation	The graph, the take and grant	Decidable	The theoretical's analysis
RBAC	The roles	The roles, the assignments, the constraints	Decidable	The enterprises' systems (the applications' RBAC, the cloud's IAM)
ABAC	The attributes	The attributes, the policies, the PEP/PDP	Decidable (the policy's language's restrictions)	The modern's systems (the cloud's zero-trust, the XACML)

The table's pattern shows the models' different focuses and their different applications. The HRU model is the theoretical's foundation (the general's matrix and its undecidability), and the restricted models (the Bell-LaPadula, the Biba, the Clark-Wilson, the Take-Grant, the RBAC, the ABAC) are the decidability's responses. The models' focuses differ: the confidentiality (the Bell-LaPadula), the integrity (the Biba, the Clark-Wilson), the rights' propagation (the Take-Grant), the roles (the RBAC), and the attributes (the ABAC). The models' applications differ: the MLS's systems (the Bell-LaPadula), the commercial's systems (the Clark-Wilson), the enterprises' systems (the RBAC), and the modern's cloud's systems (the ABAC). The observation is the reason the formal models are the authorization's theory: the models' comparison is the design's guidance, and the models' concepts (the security levels, the integrity levels, the well-formed transactions, the separation of duties, the roles, the attributes) are the real systems' designs' foundation.

4.10 The models' applications to the real systems

The formal models' concepts appear in the real systems' designs:

The SELinux's type enforcement. The SELinux's type enforcement is the Bell-LaPadula's and the Biba's concepts' extension: the subjects and the objects have the types (the labels), and the policy's rules (the allow and the deny statements) determine the accesses on the basis of the types' relationships. The SELinux's MLS's module implements the Bell-LaPadula's rules directly (the security levels and the categories), and the SELinux's integrity's extensions implement the Biba's rules' variants.
The TrustedBSD's MAC framework. The FreeBSD's and the macOS's MAC framework provides the pluggable's policy modules: the mac_biba implements the Biba model, the mac_mls implements the Bell-LaPadula model, the mac_lomac implements the Low-Watermark's variant, and the mac_partition implements the partition's policy. The framework's design is the formal models' direct's implementation: the kernel's reference monitor consults the modules, and the modules' policies are the models' rules.
The databases' Clark-Wilson's implementations. The commercial's databases (the Oracle's, the SQL Server's) implement the Clark-Wilson's concepts: the constrained data items are the database's tables with the integrity constraints, the transformation procedures are the stored procedures and the transactions, the well-formed transactions are the ACID's transactions, and the separation of duties is enforced through the roles' and the privileges' design.
The cloud's RBAC and ABAC. The cloud's identity's systems (the AWS's IAM, the Azure's RBAC, the Google's Cloud IAM) implement the RBAC's and the ABAC's concepts: the roles are the IAM's roles, the attributes are the tags and the conditions, and the policies are the JSON's policy documents (the AWS's policy language, the Azure's policy's definitions). The systems' designs are the RBAC's and the ABAC's formalizations' applications, and their scale (the millions of the users and the resources) is the models' manageability's demonstration.
The SELinux's and the AppArmor's policies. The SELinux's policy language (the type enforcement's rules, the role's assignments, the MLS's constraints) implements the RBAC's, the MAC's, and the Bell-LaPadula's concepts, and the AppArmor's profiles (the per-program's path's restrictions) implement the MAC's concepts in the path's confinement's form. The two systems' designs are the formal models' concepts' practical's realizations, and their complexity is the formal models' expressiveness's price.

4.11 Common misconceptions

"The formal models are the theory; the real systems ignore them."

The formal models are the real systems' designs' foundation. The SELinux's type enforcement, the TrustedBSD's MAC modules, the databases' integrity's constraints, and the cloud's IAM's roles and policies are the formal models' concepts' applications. The models' value is the precise reasoning: the designers use the models' concepts (the levels, the labels, the well-formed transactions, the separation of duties, the roles, the attributes) to specify the policies and to reason about their properties.

"The Bell-LaPadula and the Biba are the same model."

The two models are the dual: the Bell-LaPadula protects the confidentiality (the no read up and the no write down), and the Biba protects the integrity (the no read down and the no write up). The two models' rules' structures are the same (the two levels' comparison), but their focuses are the opposite: the Bell-LaPadula prevents the secrets' leaks (the information's flow from the lower to the higher), and the Biba prevents the corruption's propagation (the information's flow from the higher to the lower). The two models are the complementary: a system can implement the both (the SELinux's MLS and the SELinux's integrity's extensions).

"The Clark-Wilson is just the database's transactions."

The Clark-Wilson is the commercial's integrity model, and its concepts are the broader than the databases' transactions: the model specifies the constrained data items (the protected's data), the transformation procedures (the well-formed's modifications), the integrity verification procedures (the integrity's checks), and the separation of duties (the organizational's control). The model's concepts are the commercial's systems' (the accounting's, the banking's, the enterprise's software's), and the databases' transactions are the model's concepts' one's realization.

"The HRU's undecidability means the access control is impossible."

The HRU's undecidability result applies to the general access control matrix (the arbitrary commands with the arbitrary conditions and the primitive operations). The result does not mean the access control is impossible; it means the general's safety cannot be decided, so the designers must restrict the model to obtain the decidability. The restricted models (the Bell-LaPadula, the Biba, the Clark-Wilson, the Take-Grant, the RBAC, the ABAC) are the responses: each restricts the commands or the state, so the safety becomes the decidable, and each provides the policy's expressiveness within the restriction.

"The RBAC is the same as the groups."

The RBAC's formalization defines the richer's components: the roles with the hierarchy (the senior roles inherit the junior roles' permissions), the constraints (the mutually exclusive roles, the cardinality, the prerequisite), and the sessions (the role's activation's time-boundedness). The Unix's groups are the simpler (the users' sets with the shared permissions), and the RBAC's roles are the richer (the job functions with the structural's relations and the constraints).

"The ABAC is the better than the RBAC."

The ABAC and the RBAC have the different trade-offs: the ABAC is the more expressive (the fine-grained and the context-dependent's policies), and the RBAC is the more manageable (the roles' alignment with the organizations and the roles' constraints). The ABAC's expressiveness's price is the complexity (the policies' rules and their interactions, the policies' verification, the attributes' management), and the RBAC's manageability's price is the static's nature (the roles are the assigned, not the computed from the context). The two models are the complementary, and the modern's systems combine them (the role's attributes, the attribute-based's roles).

"The models' safety is the only property."

The safety is the formal models' central property, but it is not the only one. The models' other properties are the consistency (the policy's rules have no conflicts), the completeness (the policy covers the every access), the availability (the policy does not deny the legitimate's accesses), and the least privilege (the policy grants the minimum's privileges). The properties' analysis is the formal models' value, and the models' designs are the properties' balances.

"The formal models are the obsolete."

The formal models are the modern systems' designs' foundation: the SELinux's and the AppArmor's policies, the databases' integrity's constraints, the cloud's IAM's roles and policies, and the modern's zero-trust's architectures are the formal models' concepts' applications. The models' value is the precise reasoning that the specifications allow, and the models' concepts are the security's vocabulary: the security levels, the integrity levels, the well-formed transactions, the separation of duties, the roles, the attributes.

05 Worked example

The following example applies the formal models to a concrete scenario, computes the Bell-LaPadula's and the Biba's decisions, and compares the models' expressions of the same policy.

The Bell-LaPadula's and the Biba's decisions

Consider a military's system with the four security levels: the unclassified (the 0), the confidential (the 1), the secret (the 2), and the top secret (the 3). The subjects and the objects are assigned the levels and the categories. The subjects:

Alice: the level secret (the 2), the categories {nato, nuclear}.
Bob: the level confidential (the 1), the categories {nato}.
Carol: the level top secret (the 3), the categories {nato, nuclear, crypto}.

The objects:

file1: the level confidential (the 1), the categories {nato}.
file2: the level secret (the 2), the categories {nato, nuclear}.
file3: the level top secret (the 3), the categories {nato, nuclear, crypto}.
file4: the level unclassified (the 0), the categories {}.

The Bell-LaPadula's decisions (the read and the write) for each subject and each object:

Subject	Object	Read (the simple security property)	Write (the *-property)
Alice	file1 (the confidential, {nato})	✓ (the secret dominates the confidential and the categories match)	✗ (the confidential does not dominate the secret)
Alice	file2 (the secret, {nato, nuclear})	✓ (the levels and the categories match)	✓ (the levels and the categories match)
Alice	file3 (the top secret, {nato, nuclear, crypto})	✗ (the secret does not dominate the top secret)	✗ (the categories do not match: the crypto is missing)
Alice	file4 (the unclassified, {})	✓ (the secret dominates the unclassified)	✗ (the unclassified does not dominate the secret)
Bob	file1 (the confidential, {nato})	✓ (the levels and the categories match)	✓ (the levels and the categories match)
Bob	file4 (the unclassified, {})	✓ (the confidential dominates the unclassified)	✗ (the unclassified does not dominate the confidential)
Carol	file3 (the top secret, {nato, nuclear, crypto})	✓ (the levels and the categories match)	✓ (the levels and the categories match)
Carol	file1 (the confidential, {nato})	✓ (the top secret dominates the confidential and the categories include)	✗ (the confidential does not dominate the top secret)

The table's pattern shows the Bell-LaPadula's rules' operation: the read's check (the subject's level dominates the object's level and the categories include) and the write's check (the object's level dominates the subject's level and the subject's categories include the object's). The observation is the reason the model's rules enforce the confidentiality: the subjects can read the objects at or below their level (the no read up) and write to the objects at or above their level (the no write down), so the secrets cannot flow to the lower levels.

The Biba's decisions for the same subjects and objects (assuming the integrity levels are the reversed: the unclassified is the highest integrity and the top secret is the lowest, because the top secret's sources are the more restricted and the unclassified's sources are the more trusted):

Subject	Object	Read (the simple integrity axiom)	Write (the *-integrity axiom)
Alice (the integrity 1)	file1 (the integrity 2)	✓ (the object's integrity dominates the subject's)	✗ (the subject's integrity does not dominate the object's)
Alice (the integrity 1)	file4 (the integrity 3)	✓ (the object's integrity dominates the subject's)	✗ (the subject's integrity does not dominate the object's)
Carol (the integrity 3)	file4 (the integrity 3)	✓ (the levels match)	✓ (the levels match)
Carol (the integrity 3)	file1 (the integrity 2)	✗ (the object's integrity does not dominate the subject's)	✓ (the subject's integrity dominates the object's)

The table's pattern shows the Biba's rules' operation: the read's check (the object's integrity dominates the subject's) and the write's check (the subject's integrity dominates the object's). The observation is the reason the Biba's rules enforce the integrity: the subjects read the objects at or above their integrity (the no read down) and write to the objects at or below their integrity (the no write up), so the corrupted data cannot flow to the higher-integrity's objects.

The same policy's expressions in the four models

Consider the policy: "The financial analysts can read the financial reports of their department, and the financial managers can approve the transactions." The policy's expression in the four models:

Model	The policy's expression	The properties
DAC	The reports' owner (the department's head) grants the analysts the read's permission through the files' ACLs	The flexible, the simple, but the owner's discretion can deviate from the organization's policy
MAC	The reports have the label "financial"; the analysts have the clearance "financial" (the read), and the managers have the clearance "financial" (the read and the approve); the policy's rules enforce the labels' relationships	The centralized, the rigorous, but the rigid (the exceptions cannot be granted) and the administration is complex
RBAC	The role "analyst" has the read's permission on the "financial report" objects, the role "manager" has the read and the approve's permissions, and the users are assigned to the roles	The manageable, the organizational, but the role's explosion and the static's nature
ABAC	The subjects with the attribute "department=finance" and "role=analyst" can read the objects with the attribute "type=report" and "department=finance"; the subjects with "role=manager" can approve the objects with "type=transaction" and "department=finance"	The expressive, the context-dependent, but the complex and the verification is difficult

The table's pattern shows the four models' different expressions of the same policy. The DAC's expression is the owner's discretion, the MAC's is the labels' rules, the RBAC's is the roles' assignments, and the ABAC's is the attributes' rules. The observation is the reason the models are the complementary: each model's expression's properties (the flexibility, the rigor, the manageability, the expressiveness) determine its appropriate application, and the modern's systems combine the models to obtain the properties' balance.

Observing the models in a real system: the SELinux's policy

The SELinux's policy is the formal models' concepts' practical's realization. The SELinux system's inspection:

# Show the SELinux's status
getenforce
sestatus

# Show the files' labels (the types)
ls -Z /etc/passwd /etc/shadow /var/www/html/ 2>/dev/null

# Show the processes' labels (the domains)
ps -eZ | head -20

# Show the policy's rules (the allow statements)
sudo sesearch --allow 2>/dev/null | head -20

# Show the booleans (the policy's tunable's switches)
getsebool -a 2>/dev/null | head -20

# Show the SELinux's users and their roles
sudo semanage user -l 2>/dev/null
sudo semanage login -l 2>/dev/null

# Show the MLS's configuration (if the MLS is enabled)
sudo semanage mls -l 2>/dev/null
cat /etc/selinux/*/setrans.conf 2>/dev/null | head -10

The commands' outputs show the SELinux's policy's components: the files' labels (the types), the processes' labels (the domains), the policy's rules (the allow statements), the booleans (the tunable's switches), the SELinux's users and their roles, and the MLS's configuration. The SELinux's design is the formal models' concepts' realization: the types are the Bell-LaPadula's and the Biba's labels, the rules are the policy's statements, the booleans are the policy's tunable's parameters, and the roles are the RBAC's concepts. The observation is the reason the SELinux is the formal models' most complete's implementation: its policy's language can express the Bell-LaPadula's, the Biba's, the RBAC's, and the type enforcement's policies, and its enforcement is the kernel's reference monitor.

06 Interactive activity

Activity · explore the access control models on a live system

The goal of this activity is to use the Linux command line to inspect the formal models' concepts in the real systems: the SELinux's labels and rules, the RBAC's roles, the capabilities (the subject-centric's mechanism), and the models' applications. Work through the steps in your course VM.

Examine the SELinux's status and its labels. Use getenforce, sestatus, and ls -Z to inspect the SELinux's state.
```
# Show the SELinux's status
getenforce
sestatus

# Show the files' labels
ls -Z /etc/passwd /etc/shadow /etc/hosts
ls -Z /var/www/ /var/log/ 2>/dev/null | head -10

# Show the processes' labels
ps -eZ | head -20

# Show the current user's context
id -Z 2>/dev/null
```
What is the SELinux's mode (the enforcing, the permissive, the disabled)? What are the files' labels (the types)? What are the processes' domains? How do the labels implement the Bell-LaPadula's and the Biba's concepts?

Examine the SELinux's policy's rules. Use the SELinux's tools to inspect the policy's rules.

# Show the policy's allow rules (if the tools are installed)
sudo sesearch --allow 2>/dev/null | head -20

# Show the rules for a specific type
sudo sesearch --allow -t httpd_t 2>/dev/null | head -20

# Show the booleans (the policy's tunable's switches)
getsebool -a 2>/dev/null | head -20

# Show the SELinux's roles
sudo semanage user -l 2>/dev/null
sudo semanage login -l 2>/dev/null

# Show the contexts of a specific file
matchpathcon /etc/passwd /var/www/html 2>/dev/null

What are the policy's rules' structure (the source type, the target type, the class, the permissions)? What are the booleans? What are the SELinux's roles? How do the rules implement the MAC's policies?

Examine the RBAC's roles in the SELinux. Use the SELinux's tools to inspect the RBAC's roles.
```
# Show the SELinux's users
sudo semanage user -l 2>/dev/null

# Show the SELinux's login mappings
sudo semanage login -l 2>/dev/null

# Show the current user's roles
id -Z 2>/dev/null
sudo semanage user -l | grep $(whoami) 2>/dev/null

# Show the roles' definitions (if the policy's source is available)
grep -r 'role ' /etc/selinux/*/policy/ 2>/dev/null | head -10
```
What are the SELinux's users and their roles? What are the current user's roles? How does the SELinux's RBAC's design compare with the formal RBAC's model (the users, the roles, the permissions, the sessions)?
Examine the capabilities (the subject-centric's mechanism). Use getcap and getpcaps to inspect the capabilities.
```
# Show the files' capabilities
getcap -r / 2>/dev/null

# Show the current process's capabilities
cat /proc/self/status | grep -E 'Cap'
capsh --print 2>/dev/null | head -20

# Show a process's capabilities
sudo getpcaps 1 2>/dev/null

# Show the capabilities' definitions
man 7 capabilities | head -80
```
What are the files' capabilities? What are the current process's capabilities? How do the capabilities implement the subject-centric's access control (the capability's model)?

Test the Biba's and the Bell-LaPadula's concepts with the SELinux's booleans. Use the SELinux's booleans to observe the policy's tunability.

# Show the booleans and their values
getsebool -a 2>/dev/null | head -20

# Show a specific boolean
getsebool httpd_can_network_connect 2>/dev/null

# Change a boolean (if you have the permission)
sudo setsebool httpd_can_network_connect on 2>/dev/null
getsebool httpd_can_network_connect 2>/dev/null

# Change it back
sudo setsebool httpd_can_network_connect off 2>/dev/null

What are the booleans' purposes? What happens when a boolean is changed? How do the booleans implement the policy's tunability without the policy's rewrite?

Examine the AppArmor's profiles (if available). If your VM uses AppArmor instead of SELinux, inspect the AppArmor's profiles.
```
# Show the AppArmor's status
sudo aa-status 2>/dev/null

# Show the profiles
ls /etc/apparmor.d/ 2>/dev/null

# Show a profile's contents
sudo cat /etc/apparmor.d/usr.bin.firefox 2>/dev/null | head -30

# Show the profile's mode (the enforce, the complain)
sudo aa-status --enforced 2>/dev/null
```
What are the AppArmor's profiles? What is the profile's structure (the path's permissions)? How does the AppArmor's path's confinement compare with the SELinux's type enforcement?

Examine the capability's model in the systemd. Use the systemd's units to inspect the capabilities' assignment.

# Show a service's capabilities
systemctl cat sshd 2>/dev/null | grep -iE 'Capability|NoNewPrivileges|ProtectSystem|ProtectHome'

# Show the systemd's security's directives
man 5 systemd.exec | grep -A5 -iE 'CapabilityBoundingSet|AmbientCapabilities|NoNewPrivileges' | head -30

# Show the running services' capabilities
for svc in sshd systemd-journald cron; do
    pid=$(pgrep -x $svc | head -1)
    if [ -n "$pid" ]; then
        echo "=== $svc (PID $pid) ==="
        sudo getpcaps $pid 2>/dev/null
    fi
done

What capabilities do the services have? How does the systemd's design implement the least privilege's principle? How do the capabilities' assignments implement the capability's model?

Read the man pages. Read the man pages that document the access control models' implementations.
```
man 8 selinux
man 8 semanage
man 8 chcon
man 1 getenforce
man 1 sestatus
man 8 aa-status
man 5 apparmor.d
man 7 capabilities
man 8 setcap
man 1 getcap
man 5 systemd.exec
```
For each, write a sentence describing its main contribution to your understanding of the access control models. The man 8 selinux page documents the SELinux's implementation; the man 7 capabilities page documents the capabilities' model; the man 5 apparmor.d page documents the AppArmor's profiles.

Reflect: the access control models are the authorization's theory, and the real systems are the theory's applications. The Bell-LaPadula's confidentiality's levels, the Biba's integrity's axioms, the Clark-Wilson's well-formed transactions, the RBAC's roles and constraints, and the ABAC's attributes are the models' concepts, and the SELinux's types, the capabilities' tokens, the systemd's CapabilityBoundingSet, and the cloud's IAM's policies are the concepts' implementations. Which of the models from this lesson is the most important for the systems you use? What would you change about the models' designs if you could? How would you explain the Bell-LaPadula's "no read up" and the Biba's "no read down" to someone who has never thought about it? What is the right balance between the models' rigor and the systems' practicality?

07 Knowledge check

Check your understanding

Question 1

What is the safety problem, and why is its formalization important? Describe the Harrison-Ruzzo-Ullman model and its undecidability result. What is the result's consequence for the access control's design?

Show answer

The safety problem is the question: given a policy (the initial state's permissions) and a set of the operations (the state's transformations), can the system determine whether a particular subject can ever obtain a particular permission? The problem's answer determines the policy's enforcement's complexity: a policy whose safety is the decidable can be enforced with the precise guarantees, and a policy whose safety is the undecidable cannot. The problem's formalization is important because it is the security's design's central question: the policy's safety's decidability determines whether the policy's enforcement can be verified, and the verification is the security's evidence. The Harrison-Ruzzo-Ullman (HRU) model (1976) is the access control matrix's formalization. The model's components are the subjects, the objects, the access rights, the access control matrix (the state), and the commands (the state's transformations). Each command has the condition (the precondition: the rights the subject must hold to execute the command) and the primitive operations (the postcondition: the rights the command enters and deletes in the matrix). The model's example commands are the create, the grant, and the revoke. The HRU model's central result is the safety problem's undecidability: for the general's access control matrix (the arbitrary commands with the arbitrary conditions and the primitive operations), the problem of determining whether a particular subject can ever obtain a particular right is undecidable. The result's proof is the reduction from the Turing machine's halting problem: the HRU model's commands can simulate the Turing machine's operations, so the safety problem's decision would decide the halting problem, which is the undecidable. The result's consequence for the access control's design is the restriction's necessity: the general's access control matrix's safety cannot be decided, so the designers must restrict the model to obtain the decidability. The restricted models — the Bell-LaPadula, the Biba, the Clark-Wilson, the Take-Grant, the RBAC, the ABAC — are the responses: each restricts the commands or the state, so the safety becomes the decidable, and each provides the policy's expressiveness within the restriction. The result is the formal models' design's central trade-off's articulation: the expressiveness versus the decidability, and the models are the different balances.

Question 2

Describe the Bell-LaPadula model and the Biba model. What are their components, their rules, their properties, and their relationship? Explain each model's confidentiality or integrity's enforcement.

Show answer

The Bell-LaPadula model (1973, 1976) is the mandatory access control's confidentiality model. The model's components are the security levels (the unclassified, the confidential, the secret, the top secret, the ordered), the categories (the compartments: the sets of the projects, the countries, the departments), the labels (the levels and the categories' pairs), and the state (the subjects' and the objects' current's labels and the current's access modes). The model's policy is the two rules: the simple security property (the "no read up": a subject at the level l_s can read an object at the level l_o only if l_s dominates l_o) and the *-property (the "no write down": a subject at the level l_s can write to an object at the level l_o only if l_o dominates l_s). The two rules together enforce the confidentiality: the no read up prevents the subject from reading the secrets above their clearance, and the no write down prevents the subject from leaking the secrets to the objects below their level. The information's flow is the one-direction: from the lower classifications to the higher, but not the reverse. The model's properties are the safety's decidability (the state's transitions preserve the two rules) and the confidentiality's enforcement (the secrets cannot leak). The Biba model (1977) is the integrity's model, the Bell-LaPadula's dual. The model's components are the integrity levels (the untrusted, the low, the medium, the high, the ordered), the categories, and the state. The model's policy is the two rules: the simple integrity axiom (the "no read down": a subject at the integrity level l_s can read an object at the level l_o only if l_o dominates l_s) and the *-integrity axiom (the "no write up": a subject at the integrity level l_s can write to an object at the level l_o only if l_s dominates l_o). The two rules together enforce the integrity: the no read down prevents the subject from reading the less trusted data, and the no write up prevents the subject from writing to the more trusted objects. The information's flow is the one-direction: from the higher integrity to the lower, but not the reverse. The two models' relationship is the duality: the Bell-LaPadula protects the confidentiality (the secrets cannot flow down), and the Biba protects the integrity (the corruption cannot flow up). The two models' rules' structures are the same (the two levels' comparison), but their focuses are the opposite. The observation is the reason a system can implement the both (the SELinux's MLS and the SELinux's integrity's extensions), and the two models' combination is the modern high-security's systems' standard.

Question 3

Describe the Clark-Wilson model and the Take-Grant model. What are each model's components, its policy's concepts, and its application? How do the two models differ in their approach to the access control?

Show answer

The Clark-Wilson model (1987) is the commercial's integrity model. The model's components are the constrained data items (the CDIs: the data items the model's integrity protects), the unconstrained data items (the UDIs: the data items the model's integrity does not protect), the integrity verification procedures (the IVPs: the procedures that verify the CDIs' integrity), and the transformation procedures (the TPs: the procedures that modify the CDIs through the well-formed transactions). The model's policy is the certification rules (the C1–C5: the security officer's design's requirements) and the enforcement rules (the E1–E4: the system's enforcement's requirements). The model's central concepts are the well-formed transaction (the TP that preserves the CDIs' integrity: the atomicity, the consistency, the isolation, the durability — the ACID's properties) and the separation of duties (the critical operations require the multiple subjects' involvement). The model's application is the commercial's systems: the databases (the CDIs are the tables with the integrity constraints, the TPs are the stored procedures and the transactions, the well-formed transactions are the ACID's transactions), the accounting's software, the banking's systems, and the enterprise's resource planning. The Take-Grant model (1976) is the graph-based access control model. The model's state is the directed graph: the nodes are the subjects and the objects, and the edges are the rights (the read, the write, the take, the grant). The model's operations are the transformation's rules: the take (the subject with the take right on another subject can take the other's rights), the grant (the subject with the grant right on another subject can grant the subject's rights to the other), the create (the subject creates a new node and the new edges), and the remove (the subject removes an edge). The model's purpose is the sharing's and the stealing's analysis: the model's questions are whether a subject can share the rights with another (the sharing's question) or acquire the rights without the owner's consent (the stealing's question), and the answers are the graph's properties (the tg-path for the sharing, the island for the stealing). The model's application is the theoretical's analysis: the model is the formal models' demonstration that the restricted's access control's questions can be the decidable, and its graph's concepts are the access control's theory's classical's concepts. The two models differ in their approach: the Clark-Wilson is the commercial's integrity's model (the well-formed transactions and the separation of duties, the databases' and the enterprises' systems), and the Take-Grant is the rights' propagation's model (the graph's transformations, the theoretical's analysis). The Clark-Wilson's concepts are the practical's (the databases, the accounting's software), and the Take-Grant's concepts are the theoretical's (the rights' flow's analysis).

Question 4

Describe the RBAC's formalization (the RBAC0 through the RBAC3) and the ABAC's framework (the NIST SP 800-162). What are each model's components, and how do they compare?

Show answer

The RBAC's formalization (the Sandhu et al. paper, 1996) specifies the role-based access control's components and its four variants. The model's components are the users (U), the roles (R), the permissions (P), the sessions (S), the user's assignment (UA ⊆ U × R: the users to the roles), the permission's assignment (PA ⊆ P × R: the permissions to the roles), the session's roles (the function session_roles: S → 2^R), and the permission's function (the function session_permissions: S → 2^P). The model's four variants are the RBAC0 (the base model: the components and the two assignments), the RBAC1 (the hierarchical model: the RBAC0 plus the role's hierarchy — the relation RH ⊆ R × R with the transitivity, the reflexivity, and the anti-symmetry), the RBAC2 (the constrained model: the RBAC0 plus the constraints — the mutually exclusive roles, the cardinality, the prerequisite), and the RBAC3 (the unified model: the RBAC1 plus the RBAC2). The ABAC's framework (the NIST SP 800-162, 2014) specifies the attribute-based access control's components and its reference architecture. The framework's components are the attributes (the subjects', the objects', the operations', and the environment's properties, the name-value's pairs), the policies (the rules that determine the access on the basis of the attributes' values: the boolean's expressions or the XACML's rules), and the architecture (the PEP: the policy enforcement point, the PDP: the policy decision point, the PIP: the policy information point, the PAP: the policy administration point, the context handler). The framework's flow: the subject's access's request reaches the PEP, which forwards the context to the PDP; the PDP evaluates the policies (querying the PIP for the attributes) and returns the decision; the PEP enforces it. The two models' comparison: the RBAC is the role-centric (the roles' assignments and the constraints, the manageability, the static's nature), and the ABAC is the attribute-centric (the attributes and the rules, the expressiveness, the context-dependence). The RBAC's advantages are the manageability and the organizational alignment; the ABAC's advantages are the expressiveness and the flexibility. The RBAC's disadvantages are the role's explosion and the static's nature; the ABAC's disadvantages are the complexity and the attributes' management. The two models are the complementary: the RBAC's roles can be the ABAC's attributes (the role's attribute), and the ABAC's rules can express the RBAC's policies. The modern's systems combine the two (the role's attributes, the attribute-based's roles), and the combination is the access control's practical's design.

Question 5

Compare the formal access control models (the HRU, the Bell-LaPadula, the Biba, the Clark-Wilson, the Take-Grant, the RBAC, the ABAC). What are each model's focus, its key concept, its safety's decidability, and its typical application? How do the models appear in the real systems?

Show answer

The formal access control models' comparison: the HRU focuses on the access control matrix's general, its key concept is the matrix and the commands, its safety is the undecidable, and its application is the theoretical's foundation. The Bell-LaPadula focuses on the confidentiality, its key concepts are the security levels and the two rules (the no read up and the no write down), its safety is the decidable, and its application is the MLS's systems (the SELinux's MLS, the Multics). The Biba focuses on the integrity, its key concepts are the integrity levels and the two rules (the no read down and the no write up), its safety is the decidable, and its application is the integrity's systems (the TrustedBSD's MAC, the database's integrity). The Clark-Wilson focuses on the commercial's integrity, its key concepts are the CDIs, the TPs, and the separation of duties, its safety is the decidable, and its application is the commercial's systems (the databases, the accounting's software). The Take-Grant focuses on the rights' propagation, its key concepts are the graph and the take/grant, its safety is the decidable, and its application is the theoretical's analysis. The RBAC focuses on the roles, its key concepts are the roles, the assignments, and the constraints, its safety is the decidable, and its application is the enterprises' systems (the applications' RBAC, the cloud's IAM). The ABAC focuses on the attributes, its key concepts are the attributes, the policies, and the PEP/PDP, its safety is the decidable (within the policy's language's restrictions), and its application is the modern's systems (the cloud's zero-trust, the XACML). The models appear in the real systems as follows: the SELinux's type enforcement is the Bell-LaPadula's and the Biba's concepts' extension (the types are the labels, the rules are the policy's statements); the TrustedBSD's MAC framework is the formal models' direct's implementation (the mac_biba, the mac_mls, the mac_lomac modules); the databases' Clark-Wilson's implementations are the commercial's concepts' realization (the CDIs are the tables, the TPs are the stored procedures, the well-formed transactions are the ACID's transactions); the cloud's RBAC and ABAC are the RBAC's and the ABAC's formalizations' applications (the IAM's roles, the tags and conditions, the JSON's policy documents); and the SELinux's and the AppArmor's policies are the RBAC's, the MAC's, and the Bell-LaPadula's concepts' practical's realizations. The observation is the reason the formal models are the authorization's theory: the models' comparison is the design's guidance, and the models' concepts are the real systems' designs' foundation.

08 Unit discussion

Discussion prompt

The formal access control models are the authorization's theory, and their history is the history of the security's formalization. The first model — the access control matrix (the Lampson paper, 1971) — was the simple's abstraction: the subjects, the objects, and the permissions. The matrix's formalization (the HRU model, 1976) revealed the safety problem's undecidability, and the result was the formal models' design's turning point: the general's matrix's safety cannot be decided, so the designers must restrict the model. The restricted models — the Bell-LaPadula (1973, 1976), the Biba (1977), the Take-Grant (1976), the Clark-Wilson (1987), the RBAC (1992, 1996), the ABAC (2014) — were the responses, and each restricted the model to obtain the decidability while providing the policy's expressiveness within the restriction. The models' evolution is the security's design's evolution: from the military's confidentiality (the Bell-LaPadula) to the commercial's integrity (the Clark-Wilson), from the static's roles (the RBAC) to the dynamic's attributes (the ABAC).

The trend is toward the hybrid models and the policy's verification. The classical's models were the single's focus (the confidentiality or the integrity or the roles or the attributes); the modern's systems combine the models (the SELinux's type enforcement and the MLS, the cloud's RBAC and the ABAC) to obtain the properties' balance. The hybrid's design's challenge is the models' interaction: the policies' rules from the different models can conflict, and the conflicts' resolution is the hybrid's design's central concern (the deny-overrides, the allow-overrides, the priority's ordering). The policy's verification's trend is the recognition that the modern's policies are the large and the complex, and their verification is the difficult: the policy's conflicts, the rules' interactions, the completeness, and the attributes' trustworthiness are the verification's concerns, and the verification's methods (the formal's methods, the model checking, the policy's analysis's tools) are the modern security's research's active area.

The trend also raises a question about the models' expressiveness and the enforcement's practicality. The formal models' expressiveness is the attractive (the fine-grained, the context-dependent's policies), but the expressiveness's price is the complexity (the policies' rules and their interactions, the verification's difficulty, the administration's burden). The classical's systems (the Unix's permissions' bits) are the simple and the practical, and their coarseness is the accepted's price. The modern's systems (the SELinux, the cloud's IAM) are the expressive and the complex, and their complexity is the security's price. The observation is the reason the access control's design is the balance: the expressiveness the application's security requires, the complexity the administration can bear, and the verification the assurance demands.

Which of the formal models is the most important for the modern systems, and why? Should the access control's design prioritize the expressiveness (the ABAC, the SELinux) or the simplicity (the permissions' bits, the RBAC)? How should the models' hybrid's designs resolve the policies' conflicts? How should the authorization's design evolve for the AI's systems and the Internet of Things? Post your response to the Unit 12 discussion forum and reply to at least two classmates. Supports CLO1, CLO7, and CLO8.

09 Practice exercise

This ungraded exercise consolidates the lesson and prepares you for Lesson 12.5. Aim to spend 60–90 minutes on it.

Apply the Bell-LaPadula model. A system has the four security levels (unclassified, confidential, secret, top secret) and the three categories (nato, nuclear, crypto). The subjects and the objects:
- Alice: the level secret, the categories {nato, nuclear}.
- Bob: the level confidential, the categories {nato}.
- Carol: the level top secret, the categories {nato, nuclear, crypto}.
- file1: the level confidential, the categories {nato}.
- file2: the level secret, the categories {nato, nuclear}.
- file3: the level top secret, the categories {nato, nuclear, crypto}.
- file4: the level unclassified, the categories {}.
For each (the subject, the object) pair, determine whether the read and the write are allowed by the simple security property and the *-property. Explain the decisions.
Apply the Biba model. For the same subjects and objects, assume the integrity levels are the reversed (the unclassified has the highest integrity, the top secret has the lowest). For each (the subject, the object) pair, determine whether the read and the write are allowed by the simple integrity axiom and the *-integrity axiom. Explain the decisions and compare them with the Bell-LaPadula's decisions.
Analyze the Clark-Wilson model. A bank's transaction system is being designed with the Clark-Wilson model. Identify:
- The constrained data items (the CDIs).
- The unconstrained data items (the UDIs).
- The integrity verification procedures (the IVPs).
- The transformation procedures (the TPs).
- The separation of duties (the roles' constraints).
- The certification rules (the C1–C5) and the enforcement rules (the E1–E4) for the system.
Justify your design through the model's concepts.
Design a RBAC's model. A hospital's patient-record system is being designed with the RBAC. The system's users are the doctors, the nurses, the pharmacists, the lab's technicians, and the administrators. The system's resources are the patients' records, the prescriptions, the test results, the billing's information, and the audit's logs. Design the RBAC's model:
- Define the roles.
- Define the role's hierarchy (if any).
- Define the permissions for each role.
- Define the constraints (the separation of duties, the cardinality, the prerequisite).
- Define the sessions' design (the role's activation's time-boundedness).
- Explain how the model satisfies the least privilege's principle.
Justify your design.
Design an ABAC's policy. A cloud's service provider is designing the ABAC's policy for its customers' virtual machines. The subjects are the developers, the operators, and the auditors. The resources are the virtual machines, the storage's volumes, and the networks. The environment's attributes are the time, the location, the device, and the risk's score. Design the ABAC's policy:
- Define the subjects' attributes.
- Define the objects' attributes.
- Define the environment's attributes.
- Define the policy's rules (the who, what, when, where).
- Explain the policy's verification's challenges.
- Compare the ABAC's policy with the equivalent RBAC's policy.
Justify your design.

Explore the SELinux's policy. On your VM, examine the SELinux's policy's components:

# Show the SELinux's status
getenforce
sestatus

# Show the files' labels
ls -Z /etc/passwd /etc/shadow /var/www/html/ 2>/dev/null

# Show the processes' labels
ps -eZ | head -20

# Show the policy's rules
sudo sesearch --allow 2>/dev/null | head -20

# Show the booleans
getsebool -a 2>/dev/null | head -20

# Show the SELinux's users and roles
sudo semanage user -l 2>/dev/null
sudo semanage login -l 2>/dev/null

What are the files' types and the processes' domains? What are the policy's rules' structure? What are the booleans' purposes? How does the SELinux's policy implement the formal models' concepts?

Compare the models. Write a short essay (400–500 words) comparing the formal access control models (the HRU, the Bell-LaPadula, the Biba, the Clark-Wilson, the Take-Grant, the RBAC, the ABAC). Your essay should address:
- Each model's focus (the confidentiality, the integrity, the roles, the attributes).
- Each model's key concept.
- Each model's safety's decidability.
- Each model's advantages and disadvantages.
- Each model's typical application.
- The models' combinations in the modern systems.
Conclude with a recommendation for a hospital's system and for a cloud's service.
Analyze a real system's authorization's design. Choose a real system (the SELinux, the AppArmor, the AWS's IAM, the Azure's RBAC, a database's role's system) and analyze its authorization's design through the formal models:
- Which formal models does the system implement?
- How does the system's policy's language express the models' concepts?
- What are the system's policy's properties (the safety, the consistency, the completeness)?
- What are the system's advantages and disadvantages?
- How does the system's design compare with the formal models' predictions?
Write a short report (500–750 words).
Reflect. In your own words, explain the role of the formal access control models and the safety problem, and describe the Bell-LaPadula, the Biba, the Clark-Wilson, the RBAC, and the ABAC models' key concepts. Then describe one situation in your own experience — a system you have administered or used — where the access control's model affected the security or the manageability. What was the system, and how would a different model have changed the outcome?

10 Summary

The formal access control models are the authorization's theory: the mathematical's frameworks that specify the policies precisely and let the designers prove the policies' properties. Their central question is the safety problem: can a subject ever obtain a permission the policy did not intend to grant?
The Harrison-Ruzzo-Ullman (HRU) model is the access control matrix's formalization: the subjects, the objects, the rights, the matrix (the state), and the commands (the transformations). Its central result is the safety problem's undecidability for the general's matrix, which motivates the restricted models.
The Bell-LaPadula model is the confidentiality's model: the security levels and the categories, the simple security property (the no read up), and the *-property (the no write down). The two rules prevent the secrets' leaks, and the model's safety is decidable.
The Biba model is the integrity's model, the Bell-LaPadula's dual: the integrity levels, the simple integrity axiom (the no read down), and the *-integrity axiom (the no write up). The two rules prevent the corruption's propagation, and the model's safety is decidable.
The Clark-Wilson model is the commercial's integrity model: the constrained data items (the CDIs), the unconstrained data items (the UDIs), the integrity verification procedures (the IVPs), the transformation procedures (the TPs), the well-formed transactions, and the separation of duties. Its application is the commercial's systems (the databases, the accounting's software).
The Take-Grant model is the graph-based model: the graph's state, the take/grant/create/remove's rules, and the sharing's and the stealing's analysis. Its value is the theoretical's demonstration that the restricted's questions can be the decidable.
The RBAC's formalization specifies the role-based model's components (the users, the roles, the permissions, the sessions, the user's assignment, the permission's assignment, the session's functions) and its four variants (the RBAC0 through the RBAC3). The RBAC is the enterprises' standard.
The ABAC's framework (the NIST SP 800-162) specifies the attribute-based model's components (the attributes, the policies, the PEP/PDP/PIP/PAP architecture). The ABAC is the modern systems' emerging model, and its expressiveness's price is the complexity.
The models appear in the real systems: the SELinux's type enforcement (the Bell-LaPadula's and the Biba's concepts), the TrustedBSD's MAC framework (the formal models' direct implementation), the databases' Clark-Wilson's implementations (the CDIs, the TPs, the well-formed transactions), and the cloud's RBAC and ABAC (the IAM's roles and policies).

Looking ahead

This lesson presented the formal access control models: the role of the formal models and the safety problem, the HRU model and its undecidability result, the Bell-LaPadula and the Biba models, the Clark-Wilson and the Take-Grant models, the RBAC's formalization, the ABAC's framework, the models' comparison, and the models' applications to the real systems. It referred several times to the Linux security — the SELinux's type enforcement, the AppArmor's profiles, the capabilities, the systemd's CapabilityBoundingSet — and to the operating system's security's mechanisms. Lesson 12.5 presents Linux security in detail: the Linux's security's architecture, the authentication's stack (the PAM, the NSS), the authorization's mechanisms (the permissions' bits, the ACLs, the capabilities, the SELinux, the AppArmor), the auditing's subsystem (the auditd), the security's modules (the LSM), and the hardening's practices. The lesson is the unit's synthesis of the operating system's security's mechanisms, and it is the bridge to the sandboxing and the hardening that the following lessons present.

11 References

Silberschatz, A., Galvin, P. B., & Gagne, G. Operating System Concepts, 10th ed., Chapter 17, Sections 17.1–17.5.
Arpaci-Dusseau, R. H., & Arpaci-Dusseau, A. C. Operating Systems: Three Easy Pieces, the Security chapters. Available online at ostep.org.
Tanenbaum, A. S., & Bos, H. Modern Operating Systems, 4th ed., Chapter 9, Sections 9.7–9.9.
Lampson, B. W. Protection. Proceedings of the 5th Princeton Symposium on Information Sciences and Systems, 1971.
Harrison, M. A., Ruzzo, W. L., & Ullman, J. D. Protection in Operating Systems. Communications of the ACM, 1976.
Bell, D. E., & LaPadula, L. J. Secure Computer System: Unified Exposition and Multics Interpretation. MITRE Technical Report, 1976.
Biba, K. J. Integrity Considerations in Secure Computer Systems. MITRE Technical Report, 1977.
Clark, D. D., & Wilson, D. R. A Comparison of Commercial and Military Computer Security Policies. IEEE Symposium on Security and Privacy, 1987.
Sandhu, R. S., Coyne, E. J., Feinstein, H. L., & Youman, C. E. Role-Based Access Control Models. IEEE Computer, 1996.
Hu, V. C., Ferraiolo, D. F., & Kuhn, D. R. Guide to Attribute Based Access Control (ABAC) Definition and Considerations. NIST SP 800-162, 2014.
Bishop, M. Computer Security: Art and Science, 2nd ed. Addison-Wesley, 2019.
Linux man-pages: man 8 selinux, man 8 semanage, man 8 chcon, man 1 getenforce, man 1 sestatus, man 8 aa-status, man 5 apparmor.d, man 7 capabilities, man 8 setcap, man 1 getcap, man 5 systemd.exec.