Lesson 12.3: Authorization

01 Introduction

Lesson 12.1 presented the security's principles and introduced the AAA model: the authentication, the authorization, and the accounting. Lesson 12.2 presented the authentication's mechanisms in detail. This lesson presents the second pillar: authorization.

Authorization is the process of determining what an authenticated subject is allowed to do. The authentication answers the question "who are you?", and the authorization answers the question "what can you do?". The two are the security's sequential decisions: the subject is authenticated first, and the subject's privileges are determined second. The authorization's design determines the system's security policy's granularity (how precisely the policy can distinguish the subjects and the objects), its flexibility (how easily the policy can be changed), and its manageability (how easily the policy can be administered). The three properties conflict — a fine-grained policy is flexible but hard to manage, a coarse-grained policy is easy to manage but inflexible — and the authorization's models are the different balances.

The authorization's central abstraction is the access control matrix: a two-dimensional table whose rows are the subjects (the users, the processes, the roles), whose columns are the objects (the files, the devices, the network's connections), and whose entries are the permissions (the operations the subject may perform on the object). The matrix's entries can be as simple as the read/write/execute's bits or as complex as the arbitrary conditions (the time of the day, the subject's location, the object's classification). The matrix's implementation's choices — the access control lists (the columns) or the capabilities (the rows) — are the authorization's first design decision, and their trade-offs shape the rest of the design.

The authorization's models are the different ways the matrix's entries are determined. The discretionary access control (the DAC) lets the objects' owners determine the entries; the mandatory access control (the MAC) lets the system's policy determine the entries, based on the subjects' and the objects' labels; the role-based access control (the RBAC) determines the entries through the subjects' roles; and the attribute-based access control (the ABAC) determines the entries through the subjects', the objects', and the environment's attributes. The four models are the authorization's design space, and their combinations are the modern systems' implementations.

This lesson presents the authorization. It defines the authorization and distinguishes it from the authentication and the identification. It presents the authorization's components (the subjects, the objects, the operations, the permissions) and the access control matrix and its implementations (the ACLs and the capabilities). It presents the four authorization's models — the DAC, the MAC, the RBAC, and the ABAC — with each model's principles, mechanisms, advantages, and disadvantages. It presents the authorization's mechanisms (the permissions' bits, the ACLs, the capabilities, the security labels) and the policy's specification and enforcement (the reference monitor, the policy languages, the policy's verification). It presents the principle of least privilege, the separation of duties, the delegation and the revocation, and the authorization's lifecycle. It closes with the authorization's design principles and the lesson's synthesis.

Prerequisites

This lesson builds on Lessons 12.1 and 12.2. The security's goals (the CIA triad), the AAA model, the Saltzer and Schroeder principles, and the reference monitor are assumed (Lesson 12.1), and the authentication's mechanisms and the distinction from the identification are assumed (Lesson 12.2). The file system's permissions (Lesson 10.2) and the process's credentials (Lesson 3.1) are the context for the Linux authorization's discussion, and the user's identity's files (/etc/passwd, the /etc/group) from Lesson 12.2 are the context for the permissions' bits. No new operating-system concepts are introduced; the lesson is about the authorization's models and mechanisms. Familiarity with the Linux command line from Lesson 2.2 is helpful, since the interactive activity uses the chmod, chown, setfacl, getfacl, and setcap commands.

02 Learning objectives

By the end of this lesson you will be able to

Distinguish the authorization from the authentication and the identification, and describe the authorization's components (the subjects, the objects, the operations, and the permissions).
Describe the access control matrix and its two implementations (the access control lists and the capabilities), and explain each implementation's advantages and disadvantages.
Describe the discretionary access control (DAC) and its mechanisms (the permissions' bits, the ACLs, the ownership), and explain the DAC's advantages and disadvantages.
Describe the mandatory access control (MAC) and its models (the Bell-LaPadula and the Biba), and explain the MAC's advantages and disadvantages.
Describe the role-based access control (RBAC) and the attribute-based access control (ABAC), and explain each model's role, its mechanisms, and its trade-offs.
Explain the policy's specification and enforcement (the reference monitor, the policy languages, the policy's verification), the principle of least privilege, the separation of duties, the delegation and the revocation, and the authorization's design principles.

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

03 Required reading

Operating System Concepts — Chapter 16, Security, the sections on the access control and the protection's mechanisms, and Chapter 17, Protection, Sections 17.1–17.5. The standard treatment of the protection's goals, the access control matrix, the ACLs, the capabilities, and the protection's models.
OSTEP — the Security chapters, particularly the discussion of the access control and the authorization's mechanisms. OSTEP's treatment of the access control matrix and the capabilities is the clearest available account, 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 (the access control, the capabilities, and the protection's models). A complementary treatment that develops the authorization's mechanisms 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 authorization's classical foundation.
Saltzer, J. H., & Schroeder, M. D. — The Protection of Information in Computer Systems. Proceedings of the IEEE, 1975. Sections II and III discuss the access control and the protection's mechanisms, and the paper's design principles (Lesson 12.1) are the authorization's design's foundation.
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 model's components.
Ferraiolo, D. F., & Kuhn, D. R. — Role-Based Access Controls. Proceedings of the 15th National Computer Security Conference, 1992. The paper that introduced the role-based access control.
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.
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 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.
Linux man pages: man 1 chmod, man 1 chown, man 1 chgrp, man 1 umask, man 1 setfacl, man 1 getfacl, man 5 acl, man 7 capabilities, man 8 setcap, man 1 getcap, man 5 sudoers, man 8 sudo, man 8 selinux, man 8 semanage, man 8 chcon, man 8 aa-status, man 5 apparmor.d, man 1 id, man 1 stat.

Reading strategy

Read the Silberschatz chapter first. It develops the protection's goals and the access control matrix, and shows step by step how the matrix is implemented by the ACLs (the columns) and the capabilities (the rows). The chapter's comparison of the two implementations — the ACLs' lookup's efficiency versus the capabilities' revocation's difficulty — is the authorization's central trade-off, and its discussion of the protection's models is the context for the modern systems' designs. Then read the OSTEP and the Tanenbaum chapters for the complementary views, and the Lampson paper for the historical foundation. The RBAC's and the ABAC's papers (the Sandhu et al. and the Ferraiolo & Kuhn, and the NIST SP 800-162) are the modern models' sources, and they are worth reading for the models' formalizations and their design's rationales. The Bell-LaPadula and the Biba papers are the mandatory access control's classical models, and they are worth reading for the information flow's formalization. Finally, the Linux man pages are the practical tools: chmod and chown manage the permissions' bits, setfacl and getfacl manage the ACLs, setcap and getcap manage the capabilities, and chcon and semanage manage the SELinux's labels. Pay particular attention to the distinction between the authorization's model (how the policy is specified: the DAC, the MAC, the RBAC, the ABAC) and the authorization's mechanism (how the policy is enforced: the ACLs, the capabilities, the permissions' bits, the labels). The two are the authorization's design's independent dimensions, and their combinations are the modern systems' designs: a system can enforce the DAC with the permissions' bits (the classical Unix) or with the ACLs (the modern Linux), and it can enforce the MAC with the labels (the SELinux) or with the path's confinement (the AppArmor).

04 Core content

4.1 The authorization's role in the AAA model

The AAA model (Lesson 12.1) comprises the authentication, the authorization, and the accounting. The three are the security's operational sequence, and their distinction is the security's design's first decision:

Authentication answers "who are you?" — the subject's identity's verification. The result is the subject's principal: the identity that the subsequent operations use.
Authorization answers "what can you do?" — the authenticated principal's privileges' determination. The result is the access's decision: the principal's request to access a resource is granted or denied.
Accounting answers "what did you do?" — the subject's actions' recording. The result is the audit's trail: the security-relevant events' log.

The authorization's position in the sequence is the bridge: the authentication's result (the principal) is the authorization's input, and the authorization's result (the access's decision) is the accounting's subject. The observation is the reason the authorization's design depends on the authentication's design: a system with the weak authentication has the weak authorization (the attacker who impersonates the principal inherits the principal's privileges), and a system with the strong authentication but the coarse-grained authorization is the over-privileged (the authenticated user has more privileges than the task requires).

The authorization is often confused with the access control, and the distinction is worth making. The authorization is the decision: the determination of whether the subject's request should be granted. The access control is the mechanism: the enforcement of the decision (the reference monitor's check, the kernel's permission's check, the application's gate). The two are the decision and the enforcement, and the authorization's models (the DAC, the MAC, the RBAC, the ABAC) are the decision's frameworks, while the access control's mechanisms (the ACLs, the capabilities, the permissions' bits, the labels) are the enforcement's tools.

4.2 The authorization's components

The authorization's components are the four elements that every access control's decision involves:

Subject: The entity that requests the access: the user, the process, the thread, the role, the group. The subject is the active entity, and the authorization's decision is the subject's request's response. In the operating system's context, the subject is the process (with the credentials the process runs with: the effective's user ID, the effective's group ID, the supplementary's groups, the capabilities), and the user's identity is the process's owner or its credentials.
Object: The entity that the subject requests the access to: the file, the directory, the device, the socket, the shared memory's segment, the process, the system's resource. The object is the passive entity, and the authorization's decision determines the subject's permitted operations on the object.
Operation: The action the subject requests: the read, the write, the execute, the delete, the create, the rename, the append, the connect, the bind, the send, the receive, the ioctl. The operations are the verbs of the authorization's language, and their granularity determines the policy's precision: a coarse-grained policy distinguishes only the read and the write, and a fine-grained policy distinguishes the many operations.
Permission (or right, or privilege): The authorization's decision's unit: the subject's permitted operation on the object. The permissions are the access control matrix's entries, and their representation — the bits, the lists, the capabilities, the labels — is the authorization's mechanism's choice. The permissions can be the positive (the explicit grant: the subject may perform the operation) or the negative (the explicit denial: the subject may not perform the operation), and the two kinds' combination is the policy's conflict's resolution's concern (the deny overrides or the allow overrides rule).

The four components are the authorization's vocabulary, and their precise definition is the policy's specification's first step. The observation is the reason the authorization's design begins with the components' definition: a system that does not define its subjects (the users? the roles? the processes?), its objects (the files? the records? the fields?), its operations (the read and the write? the finer granularity?), and its permissions (the positive? the negative?) cannot specify its policy, and a system without the policy cannot enforce it.

4.3 The access control matrix

The access control matrix is the authorization's central abstraction: a two-dimensional table whose rows are the subjects, whose columns are the objects, and whose entries are the subjects' permissions on the objects. The matrix's entry [s, o] is the set of the operations that the subject s may perform on the object o.

The matrix's example for a small system:

An example access control matrix
Subject	file1	file2	file3	printer
alice	read, write	read	—	print
bob	read	read, write, execute	—	—
carol	—	—	read, write, delete	print

The matrix's abstraction is the authorization's specification's ideal: the policy is the matrix's contents, and the enforcement is the matrix's lookup. The abstraction's problem is its size: a system with the thousands of the subjects and the millions of the objects has the matrix with the billions of the entries, and the matrix's storage and its maintenance are the infeasible. The observation is the reason the matrix is the conceptual model, and the implementations are the matrix's two sparse representations:

The access control lists (the ACLs) store the matrix by the columns: each object has a list of the (subject, permissions) pairs, and the list is the object's ACL. The ACL's lookup (the "may the subject s perform the operation op on the object o?" check) finds the object's list and searches the subject's entry, so the lookup's cost is the list's length. The ACL's revocation (the removal of the subject's permission) is the straightforward: the subject's entry is removed from the object's list.
The capabilities store the matrix by the rows: each subject has a list of the (object, permissions) pairs, and the list is the subject's capability's list (the capability is the unforgeable token that the subject holds and presents for the access). The capability's lookup (the subject's request's check) finds the subject's list and searches the object's entry, so the lookup's cost is the list's length. The capability's revocation (the removal of the subject's permission) is the difficult: the capability is the subject's possession, and the system cannot easily find and invalidate the copies the subject may have distributed.

The two implementations' trade-off is the classical authorization's design's decision:

The ACLs and the capabilities' comparison
Property	ACLs (the columns)	Capabilities (the rows)
The lookup's direction	The object to the subjects	The subject to the objects
The lookup's cost	The object's list's length	The subject's list's length
The revocation	The easy (the entry's removal)	The difficult (the copies' distribution)
The review	The easy (the object's permissions' list)	The difficult (the subject's capabilities' list)
The delegation	The difficult	The natural (the capability's transfer)
The storage	With the objects	With the subjects
The example	The Unix's permissions' bits, the ACLs, the SELinux's policies	The file descriptors, the Kerberos's tickets, the capabilities

The table's pattern shows the two implementations' complementary's characters. The ACLs are the object-centric: they are natural for the systems where the objects' permissions are the administration's focus (the file systems, the databases), and they make the review (the "who can access this object?") the easy. The capabilities are the subject-centric: they are natural for the systems where the subjects' privileges are the administration's focus (the operating systems' kernels, the distributed systems), and they make the delegation the natural. The modern systems use the hybrid approaches (the Linux's file descriptors are the capabilities for the files, and the files' permissions are the ACLs; the SELinux's policies combine the labels' capabilities with the type-enforcement's ACLs).

Figure 12.3 — The access control matrix and its two implementations. The matrix's rows are the subjects, its columns are the objects, and its entries are the permissions. The access control lists (the ACLs) store the matrix by the columns (each object's list of the subjects and their permissions), and the capabilities store it by the rows (each subject's list of the objects and the permissions). The ACLs make the lookup (the object to the subjects) and the revocation the easy; the capabilities make the lookup (the subject to the objects) and the delegation the natural. The four authorization's models — the DAC, the MAC, the RBAC, and the ABAC — are the different ways the matrix's entries are determined.

4.4 Discretionary access control (DAC)

The discretionary access control (the DAC) is the authorization's model in which the object's owner determines the object's permissions. The owner — the subject who created the object, or the subject to whom the ownership was transferred — can grant and revoke the other subjects' permissions at the owner's discretion. The model's name reflects the discretion: the owner's judgment, not the system's policy, determines the access.

The DAC's mechanisms are the classical file systems' permissions:

The permissions' bits (the Unix's mode). The file's mode has the nine bits: the owner's, the group's, and the others' read, write, and execute's permissions (the rwxrwxrwx). The mode's three categories are the coarse-grained: the owner (the file's user), the group (the file's group), and the others (everyone else), and the nine bits specify the three categories' permissions. The mode's advantages are the simplicity and the efficiency (the nine bits are the fast to check and the compact to store); its disadvantages are the coarseness (the model cannot express the per-user's permissions beyond the owner, the group, and the others).
The access control lists (the POSIX ACLs). The file's ACL is the list of the (user or group, permissions) entries, and the list's entries override the mode's categories. The ACL's advantages are the granularity (the per-user's and the per-group's permissions) and the compatibility (the ACLs extend the mode's bits, and the mode's categories remain the fallback); its disadvantages are the complexity (the ACLs' syntax, the default's ACLs, the mask's interaction with the mode) and the storage (the ACLs' metadata's overhead).

The DAC's advantages are its flexibility and its simplicity: the owner's discretion makes the policy's changes the easy (the owner grants and revokes the permissions without the administrator's intervention), and the model's mechanisms (the bits, the ACLs) are the simple to implement and the efficient to check. Its disadvantages are its security's weakness and its administration's burden:

The security's weakness. The DAC does not control the information's flow: the subject who has the read's permission can copy the object's contents to another object (the subject's own file), and the copy inherits the subject's permissions, not the original's. The observation is the reason the DAC cannot enforce the confidentiality's policies: a secret's read's permission's holder can leak the secret, and the DAC's mechanisms cannot prevent the leak. The classical example is the Trojan horse: a program that runs with the user's privileges can read the user's files and send them to the attacker, and the DAC's mechanisms do not distinguish the user's intent from the program's.
The administration's burden. The DAC's flexibility is the decentralized: the owners determine the permissions, and the system's administrator has the limited visibility and control. The decentralized's consequence is the permission's sprawl: the owners grant the permissions generously (the convenience's preference), the permissions accumulate, and the system's policy drifts from the organization's requirements. The observation is the reason the regulated environments (the healthcare, the finance, the government) prefer the centralized models (the MAC, the RBAC).

The DAC is the classical Unix's model, and it remains the most common: the file systems' permissions' bits, the Windows's ACLs, and the modern file systems' extended ACLs are the DAC's mechanisms. The model's persistence is the evidence of its utility: the DAC is the right model for the personal systems and the small-scale's file sharing, where the owners' discretion is the appropriate and the administration's burden is the acceptable.

4.5 Mandatory access control (MAC)

The mandatory access control (the MAC) is the authorization's model in which the system's policy determines the access, regardless of the objects' owners' wishes. The model's name reflects the mandatory character: the policy is the system-wide, and the owners cannot override it. The MAC's mechanisms are the security labels: the subjects and the objects are assigned the labels (the classifications, the categories, the types), and the policy's rules determine the accesses on the basis of the labels' relationships.

The MAC's classical models are:

Bell-LaPadula (the confidentiality's model): The model that protects the confidentiality through the two rules: the no read up (the subject cannot read the objects with the higher classification: the simple security property) and the no write down (the subject cannot write to the objects with the lower classification: the *-property or the star property). The two rules prevent the information's flow from the higher classifications to the lower: a subject with the secret's clearance can read the secret's documents (the no read up), but the subject cannot copy the secret's contents to the unclassified's file (the no write down). The model's motivation is the military's classifications (the unclassified, the confidential, the secret, the top secret), and its rules are the classical confidentiality's enforcement.
Biba (the integrity's model): The model that protects the integrity through the two rules: the no read down (the subject cannot read the objects with the lower integrity: the simple integrity axiom) and the no write up (the subject cannot write to the objects with the higher integrity: the *-integrity axiom). The two rules prevent the information's flow from the lower integrity to the higher: a subject with the high integrity cannot read the low-integrity's data (the no read down) and cannot write the low-integrity's data to the high-integrity's objects (the no write up). The model's motivation is the integrity's protection (the system's critical data's protection from the untrusted sources), and its rules are the classical integrity's enforcement.

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). Their rules' structures are the same (the two levels' comparison), and the modern systems' implementations (the SELinux's type enforcement, the AppArmor's path confinement, the TrustedBSD's MAC framework) are the models' variants and their extensions.

The MAC's advantages are its security's strength and its centralization: the policy is the system-wide, so the individual subjects cannot override it, and the information's flow is the controlled (the Bell-LaPadula's and the Biba's rules prevent the leaks and the corruptions); the policy's administration is the centralized, so the organization's requirements can be enforced consistently. Its disadvantages are its rigidity and its administration's complexity: the labels' assignment and the policy's rules are the burdensome (the administrator must classify the objects and the subjects and specify the rules), and the model's rigidity can interfere with the legitimate's work (the subject who needs the exception to the policy cannot override it). The observation is the reason the MAC is the regulated environments' model (the government, the military, the healthcare, the finance) and not the general-purpose's: the MAC's security's strength's price is the administration's burden and the flexibility's loss.

4.6 Role-based access control (RBAC)

The role-based access control (the RBAC) is the authorization's model in which the roles determine the access. The subjects are assigned to the roles, the roles are granted the permissions, and the subjects inherit the permissions through their roles. The model's abstraction is the role: the job function, the organizational's position, the task's responsibility, and the permissions are associated with the roles rather than the individual subjects.

The RBAC's components are:

The users (the subjects). The individuals (or the processes) who are assigned to the roles.
The roles. The job functions or the responsibility's sets (the doctor, the nurse, the pharmacist, the administrator). The roles are the model's central abstraction, and their assignment's structure is the role's hierarchy (the senior roles inherit the junior roles' permissions: the doctor inherits the nurse's permissions).
The permissions. The operations on the objects (the read, the write, the prescribe, the dispense). The permissions are assigned to the roles, not the users.
The sessions. The user's activation of a role (the user logs in, the session's roles are the subset of the user's roles, and the session's permissions are the union of the roles' permissions). The session's concept lets the user have the many roles (the doctor who is also the researcher) and activate the subset for the current task.
The constraints. The rules that restrict the roles' assignment and the sessions' activation. The classical constraints are the separation of duties (the mutually exclusive roles: the same user cannot be both the requester and the approver), the cardinality (the maximum number of the users per role), and the prerequisite (the role's assignment requires another role).

The RBAC's advantages are its manageability and its alignment with the organizations: the permissions are associated with the roles (the job functions), so the administration is the natural (the organization's structure is the roles' structure), and the changes are the manageable (the employee's role changes, and the permissions follow). The RBAC's least privilege's enforcement is the natural: the users have the roles their job requires, and the roles' constraints (the separation of duties) prevent the conflicts. Its disadvantages are its role's explosion (the large organizations have the many roles, and the roles' management is the complex) and its static's nature (the roles are the assigned, not the computed from the context; the model cannot express the context-dependent's policies: the "the doctor can access the patient's record only when the doctor is on duty" rule).

The RBAC's variants (the Sandhu et al.'s formalization) are:

The RBAC0 (the base model). The users, the roles, the permissions, and the sessions, with the users' role's assignment and the roles' permission's assignment.
The RBAC1 (the hierarchical model). The RBAC0 plus the role's hierarchy (the senior roles inherit the junior roles' permissions).
The RBAC2 (the constrained model). The RBAC0 plus the constraints (the separation of duties, the cardinality, the prerequisite).
The RBAC3 (the unified model). The RBAC1 plus the RBAC2 (the hierarchy and the constraints).

The RBAC is the modern enterprises' standard, and its implementations are the many: the applications' role-based's systems (the content management's systems, the enterprise's resource planning), the operating systems' role-based's extensions (the Solaris's RBAC, the SELinux's roles), and the cloud's identity's systems (the AWS's IAM roles, the Azure's RBAC). The model's popularity is the evidence of its appropriateness: the RBAC's alignment with the organizations' structures makes it the natural's model for the enterprise's authorization.

4.7 Attribute-based access control (ABAC)

The attribute-based access control (the ABAC) is the authorization's model in which the attributes determine the access. The subjects, the objects, the operations, and the environment are described by the attributes (the subject's department, the object's classification, the operation's sensitivity, the time of the day, the location), and the policy's rules (the policies or the rules) determine the access on the basis of the attributes' values.

The ABAC's components are:

The subject's attributes. The properties of the subject: the identity, the role, the department, the clearance, the training's level, the location, the time of the access.
The object's attributes. The properties of the object: the owner, the classification, the type, the creation's date, the sensitivity, the retention's policy.
The operation's attributes. The properties of the operation: the read, the write, the delete, the execute, the approve, the sign.
The environment's attributes. The properties of the context: the time of the day, the day of the week, the location, the network's address, the device's type, the risk's score.
The policy. The rules that determine the access on the basis of the attributes' values. The policy's language can be the simple (the boolean's expressions) or the complex (the XACML's standard: the eXtensible Access Control Markup Language).

The ABAC's advantages are its expressiveness and its flexibility: the model can express the fine-grained and the context-dependent's policies (the "the doctor can access the patient's record only when the doctor is on duty and the patient has consented" rule) that the DAC, the MAC, and the RBAC cannot express. Its disadvantages are its complexity and its verifiability: the policy's rules are the many and the interacting, so the policy's understanding and its verification are the difficult (the policy's conflicts, the rules' interactions, the completeness), and the attributes' management is the burdensome (the attributes' sources, the attributes' updates, the attributes' trustworthiness). The observation is the reason the ABAC is the modern systems' emerging model (the cloud's zero-trust's architectures, the software-defined's perimeter's systems) and not the classical's: the ABAC's expressiveness's price is the complexity's and the verification's burdens.

4.8 The authorization's mechanisms

The authorization's models are the policy's frameworks, and the authorization's mechanisms are the enforcement's tools. The mechanisms' catalogue:

The permissions' bits (the Unix's mode): The nine bits that specify the owner's, the group's, and the others' read, write, and execute's permissions. The mechanism's advantages are the simplicity and the efficiency; its disadvantages are the coarseness (the three categories only). The mechanism is the DAC's classical's implementation, and it is the most common (the Unix's and the Linux's file systems).
The access control lists (the ACLs): The list of the (subject, permissions) entries attached to the object. The mechanism's advantages are the granularity (the per-user's and the per-group's permissions) and the review's ease (the object's permissions' list); its disadvantages are the storage's overhead and the lookup's cost (the list's length). The mechanism is the DAC's and the MAC's implementation, and it is the file systems' and the applications' standard (the POSIX ACLs, the Windows's ACLs, the network's ACLs).
The capabilities: The unforgeable tokens that the subject holds and presents for the access. The mechanism's advantages are the delegation's ease (the token's transfer), the least privilege's granularity (the fine-grained's tokens), and the lookup's efficiency (the subject's list); its disadvantages are the revocation's difficulty (the tokens' copies) and the storage's management (the tokens' distribution). The mechanism is the operating systems' kernels' and the distributed systems' implementation (the file descriptors, the Kerberos's tickets, the Linux's capabilities, the Fuchsia's handles).
The security labels: The classifications attached to the subjects and the objects (the levels, the categories, the types). The mechanism's advantages are the policy's centralization (the labels and the rules) and the information's flow's control (the Bell-LaPadula's and the Biba's rules); its disadvantages are the administration's burden (the classification's assignment) and the rigidity (the policy's exceptions). The mechanism is the MAC's implementation, and it is the regulated environments' standard (the SELinux, the AppArmor, the TrustedBSD).
The role's assignments: The (user, role) and the (role, permission) mappings. The mechanism's advantages are the manageability (the roles' alignment with the organizations) and the least privilege's enforcement (the roles' constraints); its disadvantages are the role's explosion (the many roles) and the static's nature (the context's absence). The mechanism is the RBAC's implementation, and it is the enterprises' standard (the applications' RBAC, the cloud's IAM, the operating systems' RBAC).

4.9 The policy's specification and enforcement

The authorization's policy's specification and its enforcement are the two halves of the authorization's design:

The specification. The policy's specification is the what: the subjects, the objects, the operations, and the permissions' rules. The specification's language can be the informal (the administrator's guidelines), the formal (the mathematical's models: the Bell-LaPadula, the Biba, the RBAC's formalization), or the machine-readable (the XACML, the SELinux's policy's language, the AppArmor's profiles). The specification's design's concerns are the completeness (the policy covers the every access), the consistency (the policy has no conflicts), the verifiability (the policy's properties can be checked), and the maintainability (the policy can be updated).
The enforcement. The enforcement is the how: the reference monitor's checks, the kernel's permission's checks, the application's gates. The enforcement's design's concerns are the completeness (the every access is mediated), the correctness (the decision matches the policy), the tamper-proofness (the monitor cannot be bypassed), and the efficiency (the check's cost is the acceptable). The enforcement's mechanism is the reference monitor (Lesson 12.1), and its properties (the tamper-proofness, the always-invoked, the small enough to verify) are the authorization's design's requirements.

The specification and the enforcement's correspondence is the authorization's correctness's condition: the enforcement's decisions must match the specification's rules, and the correspondence's verification is the policy's verification. The verification's methods are the testing (the policy's decisions against the expected), the formal's methods (the model checking, the theorem proving), and the auditing (the decisions' review against the policy). The observation is the reason the authorization's design's verification is the security's central concern: a policy that is not enforced, or an enforcement that does not match the policy, is the security's illusion.

4.10 The principle of least privilege and the separation of duties

The two principles are the authorization's design's central concerns:

The principle of least privilege: Every subject should operate with the minimum privileges necessary to complete the task (Lesson 12.1's principle 6). The principle's rationale is the damage's limitation: a subject with the excessive privileges can damage the more when it is compromised. The principle's authorization's applications are the roles' design (the roles have the minimum's permissions), the capabilities' granularity (the fine-grained's privileges instead of the root's all-or-nothing), the sessions' time-boundedness (the privileges' activation's duration), and the just-in-time privilege's elevation (the privileges are granted when needed and revoked when not).
The separation of duties: The critical tasks should require more than one subject, so a single subject's compromise is not sufficient for the task's completion. The principle's rationale is the single-point's failure: the task that requires the two subjects' approval is the safer than the task that requires the one's. The principle's authorization's applications are the RBAC's mutually exclusive roles (the requester and the approver), the two-person's rule (the sensitive operations' dual controls), and the transaction's authorization (the large payments' multiple approvals). The principle is the separation of privilege's (Lesson 12.1's principle 5) organizational's counterpart: the technical's separation (the two factors' authentication) is the individual's, and the organizational's separation (the two persons' approval) is the group's.

4.11 Delegation, revocation, and the authorization's lifecycle

The authorization's lifecycle's concerns are the permissions' grant, their use, their delegation, and their revocation:

The grant. The permission's assignment: the owner's grant (the DAC), the policy's assignment (the MAC), the role's assignment (the RBAC), the attribute's rule (the ABAC). The grant's design's concerns are the authorization's authority (who can grant?), the granularity (what can be granted?), and the auditability (the grants' records).
The use. The permission's exercise: the subject's request, the reference's check, the access's grant or denial. The use's design's concerns are the completeness (the every access's mediation) and the efficiency (the check's cost).
The delegation. The permission's transfer: the subject who holds the permission grants it to another subject. The delegation's design's concerns are the delegation's depth (the delegate can delegate?), the delegation's scope (the whole permission or the part), and the delegation's expiry (the time-bounded's delegation). The capabilities are the delegation's natural's mechanism (the token's transfer), and the ACLs are the delegation's difficult (the subject's entry's addition).
The revocation. The permission's removal: the owner's revocation (the DAC), the policy's revocation (the MAC), the role's revocation (the RBAC). The revocation's design's concerns are the promptness (the immediate or the delayed), the scope (the single permission or the all), and the propagation (the delegated permissions' revocation). The ACLs are the revocation's easy (the entry's removal), and the capabilities are the revocation's difficult (the token's copies).

The lifecycle's design's concerns are the authorization's consistency (the grants, the uses, the delegations, and the revocations are consistent with the policy) and the authorization's auditability (the lifecycle's events are recorded). The observation is the reason the modern systems integrate the authorization with the accounting (the AAA model's third pillar): the authorization's decisions and the lifecycle's events are the security's audit's core.

4.12 The authorization's design principles

The authorization's design applies the Lesson 12.1's principles, and the specific applications are:

The least privilege (the principle 6). The subjects have the minimum's privileges: the roles' design, the capabilities' granularity, the sessions' time-boundedness.
The fail-safe defaults (the principle 2). The access's default is the denial: the subject is denied until the policy's explicit grant. The application is the default's deny policy (the SELinux's default's deny, the file systems' default's permissions), and the default's ACLs (the newly created files' permissions).
The complete mediation (the principle 3). The every access is checked: the reference monitor's always-invoked property, the system calls' mediation, the file descriptors' binding.
The economy of mechanism (the principle 1). The authorization's mechanism is the simple and the small: the small reference monitor, the simple policy's model, the minimal interfaces.
The separation of privilege (the principle 5). The critical accesses require the multiple conditions: the separation of duties, the two-person's rule, the multi-factor's authorization.
The least common mechanism (the principle 7). The authorization's mechanism's sharing is minimized: the per-process's address spaces, the per-user's resources, the isolated namespaces.
The psychological acceptability (the principle 8). The authorization's mechanism is the usable: the roles' alignment with the organizations, the natural's interfaces, the minimal's burden.
The open design (the principle 4). The authorization's mechanism is the public and the auditable: the open's policy's languages, the standard's mechanisms, the reviewable's implementations.

4.13 Common misconceptions

"The authorization is the same as the authentication."

The authentication verifies the identity (who are you?), and the authorization determines the privileges (what can you do?). The two are the security's sequential decisions: the subject is authenticated first, and the subject's privileges are determined second. A system that confuses the two (the authorization without the authentication, or the authentication without the authorization's granularity) has a design's flaw.

"The root is the only privileged user."

The root (the UID 0) is the classical Unix's superuser, but the modern systems have the finer-grained's privileges: the Linux's capabilities (the CAP_NET_ADMIN, the CAP_SYS_ADMIN, the CAP_DAC_OVERRIDE) split the root's all-or-nothing's privileges into the separate's units, so a process can have the specific's privileges without the root's whole. The observation is the least privilege's principle's application: the services run with the specific's capabilities, not the root's whole.

"The ACLs are always better than the permissions' bits."

The ACLs and the permissions' bits have the different trade-offs: the ACLs are the more granular (the per-user's and the per-group's permissions), and the bits are the simpler and the more efficient (the nine bits' check). The modern Linux's file systems support the both (the bits are the ACL's fallback), and the choice depends on the policy's requirements: the simple's sharing uses the bits, and the complex's sharing uses the ACLs.

"The MAC is the more secure than the DAC."

The MAC and the DAC have the different properties: the MAC's policy is the centralized (the system's policy), so the MAC can enforce the information's flow's control (the Bell-LaPadula, the Biba); the DAC's policy is the decentralized (the owners' discretion), so the DAC cannot prevent the leaks (the Trojan horse). The MAC's security's strength's price is the administration's burden and the flexibility's loss, and the two models are the appropriate for the different environments: the MAC for the regulated's and the high-security's, the DAC for the general-purpose's and the personal's.

"The RBAC is just the groups."

The RBAC's roles are the more than the groups: the roles have the hierarchy (the senior roles inherit the junior roles' permissions), the constraints (the separation of duties, the cardinality, the prerequisite), and the sessions (the 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).

"The capabilities are obsolete."

The capabilities are the modern systems' emerging mechanism: the Linux's capabilities (the fine-grained's privileges), the Fuchsia's handles (the kernel's objects' capabilities), the object-capability's languages (the E, the Joe-E), and the capability-based's hardware (the CHERI's architecture). The capabilities' advantages (the least privilege's granularity, the delegation's naturalness) are the modern security's requirements, and the capabilities' revival is the response to the coarse-grained's models' limitations.

"The ABAC is the future of the authorization."

The ABAC's expressiveness is the attractive (the fine-grained, the context-dependent's policies), but its complexity is the real: the policies' rules are the many and the interacting, the verification is the difficult, and the attributes' management is the burdensome. The ABAC is the modern systems' emerging model (the cloud's zero-trust's architectures), and its adoption depends on the tools' and the standards' maturity (the XACML, the policy's engines). The classical models (the DAC, the MAC, the RBAC) remain the common, and their combinations are the practical's designs.

"The authorization's policy is the same as the authorization's mechanism."

The policy is the what (the specification: the subjects, the objects, the operations, and the permissions' rules), and the mechanism is the how (the enforcement: the reference monitor, the kernel's checks, the application's gates). The two are the authorization's design's independent dimensions, and their correspondence is the authorization's correctness's condition. The observation is the reason the authorization's design separates the two: the policy can be changed without the mechanism's rebuild, and the mechanism can be verified without the policy's knowledge.

05 Worked example

The following example traces a file access through the Linux's authorization's mechanisms, computes the permissions' check, and compares the authorization's models in a concrete scenario.

Tracing a file access in Linux

Consider the user alice (the UID 1000) who runs the cat command on the file /home/bob/report.txt. The file's owner is bob (the UID 1001), its group is staff (the GID 100), and its mode is 0640 (rw-r-----). The user alice is a member of the group staff.

The access's trace:

The process's credentials. The cat process runs with alice's credentials: the effective's UID 1000, the effective's GID 100 (the staff), and the supplementary's groups (the alice belongs to).
The file's metadata. The file /home/bob/report.txt has the owner bob (the UID 1001), the group staff (the GID 100), and the mode 0640.
The permission's check. The kernel's VFS layer (the reference monitor's part) checks the process's credentials against the file's mode's three categories:
- The owner's category. The process's effective's UID (1000) is compared with the file's owner's UID (1001). They differ, so the owner's category does not apply.
- The group's category. The process's effective's GID (100) is compared with the file's group's GID (100), and the supplementary's groups are checked. The match is found (the GID 100), so the group's category applies: the group's permissions are r-- (the read).
- The others' category. The others' category is the fallback when the owner's and the group's categories do not apply. In this case, the group's category applies, so the others' category (---) is not checked.
The access's decision. The requested operation is the read, and the group's category's read's permission is granted. The kernel allows the access, and the cat command reads the file's contents.
The audit's record. The kernel's audit's subsystem (if enabled) records the access's event: the process's PID, the user's UID, the file's path, the operation, and the decision.

The trace shows the Linux's authorization's mechanism's operation: the reference monitor (the VFS layer) checks the process's credentials against the file's mode, and the decision (the allow or the deny) is the authorization's result. The mechanism is the DAC's (the owner's mode's discretion), and the check is the complete mediation's (the every access's check).

The permissions' check's variations

The same access with the different conditions:

Condition	The applicable category	The decision	The reason
`alice` is the file's owner	The owner's category	The read, the write allowed	The mode's `rw-`
`alice` is in the group `staff`	The group's category	The read allowed, the write denied	The mode's `r--`
`alice` is not in the group `staff`	The others' category	The read and the write denied	The mode's `---`
`alice` is the root	— (the override)	The read and the write allowed	The root's `CAP_DAC_OVERRIDE`
The file has an ACL granting `alice` the read	The ACL's entry	The read allowed	The ACL's entry overrides the mode's categories

The table's pattern shows the Linux's authorization's mechanisms' combination: the mode's categories (the DAC's classical), the root's override (the CAP_DAC_OVERRIDE capability), and the ACLs' extension (the granularity). The observation is the reason the Linux's authorization is the layered: the mode is the first's check, the ACL is the second's, and the capabilities are the override's.

The authorization's models' comparison

The same policy's expression in the four models:

Model	The policy's expression	The mechanism
DAC	`bob` (the owner) sets the file's mode to `0640`, granting the read to the group `staff`	The mode's bits, the ACLs
MAC	The system's policy: the files with the label `confidential` are readable by the subjects with the label `staff` and the clearance `confidential`	The SELinux's labels and the type enforcement
RBAC	The role `analyst` has the read's permission on the `report`'s objects, and `alice` is assigned the role `analyst`	The role's assignment, the role's permissions
ABAC	The subjects with the attribute `department=finance` can read the objects with the attribute `type=report` and `classification≤internal` when the environment's attribute `time` is within the working hours	The attributes, the policy's rules (the XACML)

The table's pattern shows the four models' different expressions of the same policy. The DAC's expression is the owner's discretion (the mode's bits), the MAC's is the system's labels (the classifications), the RBAC's is the role's assignment (the job functions), and the ABAC's is the attributes' rules (the context-dependent). The observation is the reason the models are the complementary: the DAC is the simple and the flexible, the MAC is the centralized and the rigorous, the RBAC is the manageable and the organizational, and the ABAC is the expressive and the context-dependent. The modern systems combine the models (the Linux's DAC plus the SELinux's MAC plus the roles), and the combination is the authorization's design's practical's answer.

Observing the authorization on a live system

The Linux tools let an administrator inspect the system's authorization's state: the files' permissions, the ACLs, the capabilities, the SELinux's labels, and the sudo's configuration.

# Show the files' permissions
ls -la /etc/passwd /etc/shadow
stat -c '%a %U:%G %n' /etc/passwd /etc/shadow

# Show a file's ACLs
getfacl /etc/passwd 2>/dev/null
getfacl /home/ 2>/dev/null

# Set an ACL and verify it
touch /tmp/acl-test.txt
setfacl -m u:nobody:rw /tmp/acl-test.txt
getfacl /tmp/acl-test.txt
rm /tmp/acl-test.txt

# Show the processes' capabilities
getcap -r / 2>/dev/null | head -10
sudo getpcaps 1 2>/dev/null

# Show the SELinux's status and the files' labels
getenforce 2>/dev/null
ls -Z /etc/passwd /etc/shadow 2>/dev/null

# Show the sudo's configuration
sudo cat /etc/sudoers | grep -vE '^#|^$'
sudo -l

# Show the process's credentials
cat /proc/self/status | grep -E 'Uid|Gid|Cap'
ps -eo pid,user,group,cmd | head -20

# Show the audit's authorization's events
sudo ausearch -m AVC -ts today 2>/dev/null | head -20
sudo ausearch -m USER_CMD -ts today 2>/dev/null | head -20

The commands' outputs show the authorization's state: the files' permissions and the ACLs, the processes' capabilities, the SELinux's labels, the sudo's configuration, the processes' credentials, and the audit's events. The inspection is the administrator's first step in the authorization's assessment, and it is the basis for the policy's hardening's decisions.

06 Interactive activity

Activity · explore the authorization on a live system

The goal of this activity is to use the Linux command line to inspect the system's authorization's mechanisms, to create and test the permissions' bits and the ACLs, to examine the capabilities and the SELinux's labels, and to test the sudo's configuration. Work through the steps in your course VM.

Inventory the files' permissions. Use ls, stat, and the find command to examine the system's files' permissions.
```
# Show the key files' permissions
ls -la /etc/passwd /etc/shadow /etc/sudoers
stat -c '%a %U:%G %n' /etc/passwd /etc/shadow

# Find the world-writable files
find / -type f -perm -o+w 2>/dev/null | head -20

# Find the setuid and setgid files
find / -perm -4000 -type f 2>/dev/null | head -20
find / -perm -2000 -type f 2>/dev/null | head -20

# Find the files without the owner
find / -nouser -o -nogroup 2>/dev/null | head -10
```
What are the key files' permissions? Are there any world-writable files? Are there any setuid files? Which files have no owner? What do the results tell you about the system's authorization's hygiene? Write down what you find.

Test the permissions' bits. Create the test files with the different modes and test the access with the different users.

# Create a test user
sudo useradd -m -s /bin/bash testbob
sudo passwd testbob
# (Enter a password.)

# Create the test files with the different modes
echo "public" > /tmp/perm-public.txt
echo "private" > /tmp/perm-private.txt
chmod 644 /tmp/perm-public.txt
chmod 600 /tmp/perm-private.txt

# Test the access as testbob
sudo -u testbob cat /tmp/perm-public.txt 2>&1
sudo -u testbob cat /tmp/perm-private.txt 2>&1

# Change the ownership and test
sudo chown testbob /tmp/perm-private.txt
sudo -u testbob cat /tmp/perm-private.txt 2>&1

# Clean up
sudo userdel -r testbob 2>/dev/null
rm /tmp/perm-public.txt /tmp/perm-private.txt

Did the testbob read the public file? Did it read the private file? What changed when the ownership was changed? What do the results tell you about the DAC's mechanism?

Test the ACLs. Create a file, set its ACL, and verify the access.

# Create a test user and a test file
sudo useradd -m -s /bin/bash testcarol
sudo passwd testcarol

touch /tmp/acl-test.txt
echo "ACL test" > /tmp/acl-test.txt

# Set the ACL granting testcarol the read
setfacl -m u:testcarol:r /tmp/acl-test.txt

# Show the ACL
getfacl /tmp/acl-test.txt

# Test the access as testcarol
sudo -u testcarol cat /tmp/acl-test.txt 2>&1

# Revoke the ACL and test again
setfacl -x u:testcarol /tmp/acl-test.txt
sudo -u testcarol cat /tmp/acl-test.txt 2>&1

# Clean up
sudo userdel -r testcarol 2>/dev/null
rm /tmp/acl-test.txt

Did the ACL grant the access? What does the ACL's getfacl output look like? Did the revocation work? How does the ACL's mechanism differ from the permissions' bits?

Examine the capabilities. Use getcap and getpcaps to examine the system's capabilities.
```
# Show the files' capabilities
getcap -r / 2>/dev/null

# Show the current process's capabilities
cat /proc/self/status | grep -E 'Cap'

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

# Show the capabilities' definitions
man 7 capabilities | head -60

# Test the capabilities (if you have a test program)
# ...
```
Which files have the capabilities? What are the current process's capabilities? What do the capabilities' definitions tell you about the fine-grained's privileges? How do the capabilities differ from the root's all-or-nothing's privileges?
Examine the SELinux or the AppArmor. Use the tools to examine the system's mandatory access control.
```
# Show the SELinux's status
getenforce 2>/dev/null
sestatus 2>/dev/null | head -10

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

# Show the AppArmor's status
sudo aa-status 2>/dev/null | head -20

# Show the SELinux's booleans (if SELinux is enabled)
getsebool -a 2>/dev/null | head -20

# Show the SELinux's contexts
id -Z 2>/dev/null
ps -eZ 2>/dev/null | head -10
```
Is the SELinux or the AppArmor enabled? What are the files' labels? What are the processes' contexts? What does the MAC's mechanism tell you about the policy's centralization and the information's flow's control?

Test the sudo's configuration. Examine the sudo's configuration and test the privilege's escalation.

# Show the sudo's configuration
sudo cat /etc/sudoers | grep -vE '^#|^$'
sudo ls /etc/sudoers.d/ 2>/dev/null

# Show the current user's sudo privileges
sudo -l

# Test a sudo command
sudo id

# Test a sudo command that is not allowed (if any)
# ...

# Show the sudo's log
sudo grep -i sudo /var/log/auth.log 2>/dev/null | tail -10
sudo journalctl -t sudo 2>/dev/null | tail -10

What are the current user's sudo privileges? Did the sudo command work? What does the sudo's log show? How does the sudo's mechanism implement the least privilege's principle?

Examine the audit's authorization's events. Use the audit's tools to examine the authorization's decisions.

# Show the audit's status
sudo auditctl -s 2>/dev/null

# Show the audit's rules
sudo auditctl -l 2>/dev/null

# Show the recent authorization's events (the AVC's
# denials for SELinux, the USER_CMD for the sudo)
sudo ausearch -m AVC -ts today 2>/dev/null | head -20
sudo ausearch -m USER_CMD -ts today 2>/dev/null | head -20
sudo ausearch -m USER_LOGIN -ts today 2>/dev/null | head -20

# Show the audit's report
sudo aureport --auth 2>/dev/null | head -20
sudo aureport --file 2>/dev/null | head -20

What are the audit's rules? What are the recent authorization's events? What do the events tell you about the system's authorization's decisions? How does the audit's subsystem help the security's operations?

Read the man pages. Read the man pages that document the authorization's interfaces.
```
man 1 chmod
man 1 chown
man 1 setfacl
man 1 getfacl
man 5 acl
man 7 capabilities
man 8 setcap
man 1 getcap
man 5 sudoers
man 8 sudo
man 8 selinux
man 8 chcon
man 8 semanage
man 5 apparmor.d
man 1 stat
```
For each, write a sentence describing its main contribution to your understanding of the authorization. The man 1 chmod page documents the permissions' bits; the man 5 acl page documents the ACLs; the man 7 capabilities page documents the Linux's capabilities; the man 5 sudoers page documents the sudo's configuration.

Reflect: the authorization is the security's second pillar, and its design is the tension between the granularity and the manageability. The permissions' bits are the simple and the efficient, but their coarseness limits the policy's precision; the ACLs are the granular, but their complexity increases the administration's burden; the MAC is the rigorous, but its rigidity limits the flexibility; the RBAC is the manageable, but its roles' explosion limits the scalability; the ABAC is the expressive, but its complexity limits the verification. Which of the authorization's models from this lesson is the most appropriate for the systems you use? What would you change about the authorization's design if you could? How would you explain the difference between the DAC and the MAC to someone who has never thought about it? What is the right balance between the security's strictness and the administration's burden?

07 Knowledge check

Check your understanding

Question 1

Distinguish the authorization from the authentication and the identification, and describe the authorization's four components (the subjects, the objects, the operations, and the permissions). Why is the distinction important?

Show answer

The identification is the subject's claim of an identity (the username), the authentication is the claim's verification (the password's check), and the authorization is the determination of what the authenticated principal is allowed to do (the access's decision). The three form the security's first conversation's sequence: the subject claims the identity, the system verifies the claim, and the system determines the privileges. The distinction is important because the three are the security's sequential decisions, and their confusion is a design's flaw: a system that trusts the identification without the authentication is trivially impersonated; a system that grants the privileges on the basis of the identity without the separate authorization's check has a coarse-grained policy; and a system that conflates the authentication and the authorization (the same credential for both) makes a single credential's compromise the whole system's compromise. The authorization's four components are the subjects (the active entities that request the access: the users, the processes, the roles), the objects (the passive entities that the access targets: the files, the devices, the records), the operations (the actions the subject requests: the read, the write, the execute), and the permissions (the authorization's decision's unit: the subject's permitted operation on the object). The four are the authorization's vocabulary, and their precise definition is the policy's specification's first step: a system that does not define its subjects, its objects, its operations, and its permissions cannot specify its policy, and a system without the policy cannot enforce it. The components' definition's choices determine the policy's granularity: the coarse-grained's subjects (the users versus the roles), the coarse-grained's objects (the files versus the records versus the fields), the coarse-grained's operations (the read and the write versus the many operations), and the coarse-grained's permissions (the positive versus the negative).

Question 2

Describe the access control matrix and its two implementations (the ACLs and the capabilities). What are each implementation's advantages and disadvantages, and when is each appropriate?

Show answer

The access control matrix is the authorization's central abstraction: a two-dimensional table whose rows are the subjects, whose columns are the objects, and whose entries are the subjects' permissions on the objects. The matrix's abstraction is the policy's specification's ideal, and its problem is its size: a system with the many subjects and the many objects has the matrix with the many entries, and the matrix's storage is the infeasible. The two implementations are the matrix's sparse representations. The access control lists (the ACLs) store the matrix by the columns: each object has a list of the (subject, permissions) pairs. The ACL's lookup (the "may the subject perform the operation on the object?" check) finds the object's list and searches the subject's entry, so the lookup's cost is the list's length. The ACL's advantages are the revocation's ease (the subject's entry's removal) and the review's ease (the object's permissions' list); its disadvantages are the delegation's difficulty (the subject's entry's addition on the other object) and the storage's distribution (the lists are with the objects). The capabilities store the matrix by the rows: each subject has a list of the (object, permissions) pairs, and the list is the subject's capabilities. The capability's lookup finds the subject's list and searches the object's entry, so the lookup's cost is the list's length. The capability's advantages are the delegation's naturalness (the token's transfer) and the least privilege's granularity (the fine-grained's tokens); its disadvantages are the revocation's difficulty (the tokens' copies' distribution) and the storage's management (the tokens' distribution). The two implementations are appropriate for the different environments: the ACLs are the object-centric's systems' (the file systems, the databases) where the objects' permissions are the administration's focus and the review is the frequent; the capabilities are the subject-centric's systems' (the operating systems' kernels, the distributed systems) where the subjects' privileges are the administration's focus and the delegation is the natural. The modern systems use the hybrid approaches: the Linux's file descriptors are the capabilities for the files, and the files' permissions are the ACLs; the SELinux's policies combine the labels' capabilities with the type-enforcement's ACLs.

Question 3

Describe the discretionary access control (DAC) and the mandatory access control (MAC). What are each model's principles, mechanisms, advantages, and disadvantages, and what are the classical MAC models (the Bell-LaPadula and the Biba)?

Show answer

The discretionary access control (the DAC) is the model in which the object's owner determines the object's permissions. The owner can grant and revoke the other subjects' permissions at the owner's discretion. The DAC's mechanisms are the permissions' bits (the Unix's nine bits: the owner's, the group's, and the others' read, write, and execute) and the access control lists (the POSIX ACLs: the per-user's and the per-group's entries that override the mode's categories). The DAC's advantages are its flexibility (the owners' discretion makes the policy's changes the easy) and its simplicity (the mechanisms are the simple to implement and the efficient to check). Its disadvantages are its security's weakness (the DAC does not control the information's flow: the subject with the read's permission can copy the object's contents, and the copy inherits the subject's permissions, not the original's; the classical example is the Trojan horse) and its administration's burden (the decentralized's permissions drift from the organization's requirements). The mandatory access control (the MAC) is the model in which the system's policy determines the access, regardless of the owners' wishes. The MAC's mechanisms are the security labels (the classifications, the categories, the types attached to the subjects and the objects) and the policy's rules (the labels' relationships). The MAC's advantages are its security's strength (the centralized's policy controls the information's flow) and its centralization (the policy is the system-wide, and the individual subjects cannot override it). Its disadvantages are its rigidity (the policy's exceptions cannot be granted) and its administration's complexity (the labels' assignment and the rules' specification are the burdensome). The MAC's classical models are the Bell-LaPadula (the confidentiality's model: the no read up — the subject cannot read the objects with the higher classification — and the no write down — the subject cannot write to the objects with the lower classification; the two rules prevent the information's flow from the higher classifications to the lower) and the Biba (the integrity's model: the no read down and the no write up; the two rules prevent the information's flow from the lower integrity to the higher). The two models are the dual: the Bell-LaPadula protects the confidentiality, and the Biba protects the integrity. The MAC's modern implementations are the SELinux's type enforcement, the AppArmor's path confinement, and the TrustedBSD's MAC framework.

Question 4

Describe the role-based access control (RBAC) and the attribute-based access control (ABAC). What are each model's components, advantages, and disadvantages, and when is each appropriate?

Show answer

The role-based access control (the RBAC) is the model in which the roles determine the access. The subjects are assigned to the roles, the roles are granted the permissions, and the subjects inherit the permissions through their roles. The RBAC's components are the users (the subjects), the roles (the job functions), the permissions (the operations on the objects), the sessions (the user's activation of the role's subset), and the constraints (the separation of duties, the cardinality, the prerequisite). The RBAC's variants are the RBAC0 (the base), the RBAC1 (the hierarchical), the RBAC2 (the constrained), and the RBAC3 (the unified). The RBAC's advantages are its manageability (the roles' alignment with the organizations) and its alignment with the organizations' structures (the administration is the natural, and the employees' role changes update the permissions). Its disadvantages are its role's explosion (the large organizations have the many roles) and its static's nature (the roles are the assigned, not the computed from the context). The RBAC is the enterprises' standard, and its implementations are the many (the applications' RBAC, the cloud's IAM, the operating systems' RBAC). The attribute-based access control (the ABAC) is the model in which the attributes determine the access. The subjects, the objects, the operations, and the environment are described by the attributes, and the policy's rules (the boolean's expressions or the XACML) determine the access on the basis of the attributes' values. The ABAC's components are the subject's attributes (the identity, the role, the department, the clearance, the location), the object's attributes (the owner, the classification, the type, the sensitivity), the operation's attributes (the read, the write, the delete), the environment's attributes (the time, the location, the device's type, the risk's score), and the policy (the rules). The ABAC's advantages are its expressiveness (the fine-grained and the context-dependent's policies) and its flexibility (the attributes' rules can express the DAC's, the MAC's, and the RBAC's policies, and beyond). Its disadvantages are its complexity (the many rules' interactions, the policy's verification's difficulty) and its management's burden (the attributes' sources, the attributes' updates, the attributes' trustworthiness). The ABAC is the modern systems' emerging model (the cloud's zero-trust's architectures), and its adoption depends on the tools' and the standards' maturity. The RBAC and the ABAC are appropriate for the different environments: the RBAC for the enterprises with the stable organizational structures (the job functions' alignment), and the ABAC for the systems with the context-dependent's policies (the healthcare's patient's consent, the finance's transaction's authorization, the cloud's zero-trust's).

Question 5

Explain the policy's specification and enforcement, the principle of least privilege, the separation of duties, the delegation and the revocation, and the authorization's design principles.

Show answer

The authorization's policy's specification is the what: the subjects, the objects, the operations, and the permissions' rules. The specification's language can be the informal (the guidelines), the formal (the mathematical's models: the Bell-LaPadula, the Biba, the RBAC), or the machine-readable (the XACML, the SELinux's policy's language). The specification's design's concerns are the completeness (the policy covers the every access), the consistency (the policy has no conflicts), the verifiability (the policy's properties can be checked), and the maintainability (the policy can be updated). The enforcement is the how: the reference monitor's checks, the kernel's permission's checks, the application's gates. The enforcement's design's concerns are the completeness (the every access is mediated), the correctness (the decision matches the policy), the tamper-proofness (the monitor cannot be bypassed), and the efficiency (the check's cost is the acceptable). The specification and the enforcement's correspondence is the authorization's correctness's condition. The principle of least privilege requires every subject to operate with the minimum privileges necessary to complete the task. Its rationale is the damage's limitation: a subject with the excessive privileges can damage the more when it is compromised. Its authorization's applications are the roles' design (the minimum's permissions), the capabilities' granularity (the fine-grained's privileges), and the sessions' time-boundedness. The separation of duties requires the critical tasks to require more than one subject, so a single subject's compromise is not sufficient. Its rationale is the single-point's failure. Its authorization's applications are the RBAC's mutually exclusive roles, the two-person's rule, and the transaction's authorization. The delegation is the permission's transfer: the subject who holds the permission grants it to another subject. The delegation's design's concerns are the delegation's depth, the delegation's scope, and the delegation's expiry. The revocation is the permission's removal: the owner's revocation (the DAC), the policy's revocation (the MAC), the role's revocation (the RBAC). The revocation's design's concerns are the promptness, the scope, and the propagation. The authorization's design principles apply the Lesson 12.1's principles: the least privilege (the minimum's privileges), the fail-safe defaults (the access's default is the denial), the complete mediation (the every access is checked), the economy of mechanism (the simple and the small), the separation of privilege (the multiple conditions), the least common mechanism (the minimized sharing), the psychological acceptability (the usable), and the open design (the public and the auditable).

08 Unit discussion

Discussion prompt

The authorization is the security's second pillar, and its history is the history of the models' evolution. The first systems used the simple's permissions' bits: the owner, the group, and the others, with the read, the write, and the execute. The bits were the sufficient for the small's systems and the simple's sharing, and their coarseness was the acceptable. The multi-user's systems and the complex's sharing required the finer granularity, and the ACLs were the response: the per-user's and the per-group's permissions. The ACLs' management's burden in the large's organizations required the abstraction's higher level, and the RBAC was the response: the roles' alignment with the organizations' structures. The context-dependent's policies required the finer's expressiveness, and the ABAC was the response: the attributes' rules. The MAC's models (the Bell-LaPadula and the Biba) were the parallel's evolution, driven by the military's and the intelligence's requirements: the classifications' labels and the information's flow's control.

The trend is toward the fine-grained and the context-aware authorization. The classical's models (the bits, the ACLs) were the object-centric and the static; the modern's models (the RBAC, the ABAC) are the subject-centric and the context-aware. The trend's driver is the workloads' change: the modern's systems (the cloud, the mobile, the IoT) have the many subjects and the many objects, the dynamic's contexts and the distributed's resources, and the classical's models cannot express the modern's policies (the "the contractor can access the project's files only during the contract's period and from the company's network" rule). The observation is the reason the ABAC is the modern systems' emerging model, and the reason the RBAC's implementations are the enterprises' standard.

The trend also raises a question about the policy's verification. The classical's models' policies were the small and the simple, and their verification was the tractable (the review, the testing). The modern's models' policies are the large and the complex (the thousands of the rules, the attributes' interactions), and their verification is the difficult (the policy's conflicts, the rules' interactions, the completeness). The observation is the reason the policy's verification is the modern security's research's active area (the formal's methods, the model checking, the policy's analysis's tools), and the reason the policy's management's tools (the SELinux's tools, the cloud's IAM's tools) are the modern's systems' essential.

Which of the authorization's models is the most appropriate for the modern's systems, and why? Should the authorization's policy be the centralized (the MAC, the RBAC, the ABAC) or the decentralized (the DAC), and who should make the trade-off's decision? How should the authorization's design evolve for the AI's systems and the Internet of Things? What is the right balance between the fine-grained's expressiveness and the verification's tractability? 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.4. Aim to spend 60–90 minutes on it.

Compare the four authorization's models. Write a short essay (400–500 words) comparing the DAC, the MAC, the RBAC, and the ABAC. Your essay should address:
- Each model's principle (who determines the access?).
- Each model's mechanisms.
- Each model's advantages.
- Each model's disadvantages.
- Each model's appropriate environments.
- The models' combinations in the modern systems.
Conclude with a recommendation for a hospital's patient-record system and for a small business's file server.
Trace the permissions' check. The user alice (the UID 1000) runs the cat command on the file /projects/secret.txt. The file's owner is carol (the UID 1001), its group is projects (the GID 200), and its mode is 0640. The user alice is in the group projects. Trace the permission's check:
- Which category applies (the owner's, the group's, or the others')?
- What are the category's permissions?
- What is the decision (the read's allow or deny)?
- What would change if the file had an ACL granting alice the read?
- What would change if alice were the root?

Test the permissions and the ACLs. On your VM, create the test files with the different permissions and the ACLs, and verify the access with the different users.

# Create the test users
sudo useradd -m -s /bin/bash testalice
sudo useradd -m -s /bin/bash testbob
sudo passwd testalice
sudo passwd testbob

# Create the test files
echo "public data" > /tmp/test-public.txt
echo "private data" > /tmp/test-private.txt
echo "acl data" > /tmp/test-acl.txt
chmod 644 /tmp/test-public.txt
chmod 600 /tmp/test-private.txt
chmod 640 /tmp/test-acl.txt

# Test the access
sudo -u testalice cat /tmp/test-public.txt 2>&1
sudo -u testalice cat /tmp/test-private.txt 2>&1

# Set an ACL and test
setfacl -m u:testalice:r /tmp/test-acl.txt
getfacl /tmp/test-acl.txt
sudo -u testalice cat /tmp/test-acl.txt 2>&1

# Clean up
sudo userdel -r testalice 2>/dev/null
sudo userdel -r testbob 2>/dev/null
rm /tmp/test-public.txt /tmp/test-private.txt /tmp/test-acl.txt

What were the results? Did the ACL change the access? How does the ACL's mechanism differ from the permissions' bits?

Design a role-based access control's model. A university's course-management system is being designed. The system's users are the students, the instructors, the teaching assistants, the administrative staff, and the administrators. The system's resources are the courses, the assignments, the grades, the announcements, and the discussion's forums. 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).
- Define the role's assignments for each user's type.
- Explain how the model satisfies the least privilege's principle.
Justify your design.
Design an attribute-based access control's policy. A hospital's patient-record system is being designed with the ABAC. The system's users are the doctors, the nurses, the pharmacists, and the patients. The system's resources are the patients' records, the prescriptions, the test results, and the billing's information. The environment's attributes are the time, the location, the device, and the emergency's flag. Design the ABAC's policy:
- Define the subject's attributes.
- Define the object's attributes.
- Define the environment's attributes.
- Define the policy's rules (the who, what, when, where).
- Explain how the model satisfies the least privilege's principle and the separation of duties.
- Explain the policy's verification's challenges.
Justify your design.
Investigate the SELinux's or the AppArmor's policy. On your VM, examine the SELinux's or the AppArmor's policy:
```
# For SELinux:
getenforce
sestatus
ls -Z /etc/passwd /etc/shadow
ps -eZ | head -10
getsebool -a | head -20
sudo semanage fcontext -l 2>/dev/null | head -10

# For AppArmor:
sudo aa-status
ls /etc/apparmor.d/
sudo cat /etc/apparmor.d/usr.bin.firefox 2>/dev/null | head -30
```
What are the policy's rules? How does the policy's model (the type enforcement for SELinux, the path confinement for AppArmor) work? How does the policy implement the MAC's principles?

Analyze the sudo's configuration. Examine and modify the sudo's configuration to implement the least privilege's principle:

# Show the current sudo's configuration
sudo cat /etc/sudoers | grep -vE '^#|^$'
sudo -l

# Create a sudoers's rule granting a user the
# specific command
sudo visudo
# (Add: testuser ALL=(ALL) /usr/bin/systemctl restart nginx)
# (Replace testuser with a real user.)

# Test the rule
sudo -u testuser sudo -l
sudo -u testuser sudo systemctl restart nginx 2>&1
sudo -u testuser sudo cat /etc/shadow 2>&1

# Show the sudo's log
sudo grep -i sudo /var/log/auth.log | tail -10

Did the specific command work? Did the unauthorized command fail? What does the sudo's log show? How does the sudo's configuration implement the least privilege's principle?

Compare the authorization's mechanisms. Write a short paragraph (200–250 words) comparing the authorization's mechanisms (the permissions' bits, the ACLs, the capabilities, the security labels, the role's assignments). Your paragraph should address:
- Each mechanism's representation of the access control matrix.
- Each mechanism's advantages.
- Each mechanism's disadvantages.
- Each mechanism's appropriate use's cases.
- The mechanisms' combinations in the modern systems.
Design an authorization's policy. A cloud's service provider is designing the authorization's policy for its customers' virtual machines. The customers are the different organizations, and the organizations' users are the developers, the operators, and the auditors. The resources are the virtual machines, the storage's volumes, the networks, and the billing's information. Design the authorization's policy:
- Which model (the DAC, the MAC, the RBAC, the ABAC) would you use for the different resources, and why?
- Which mechanisms (the ACLs, the capabilities, the labels) would you use, and why?
- How would you handle the tenants' isolation?
- How would you handle the cross-tenant's sharing (if any)?
- How would you handle the authorization's lifecycle (the grants, the delegations, the revocations)?
- How would you verify the policy's correctness?
Justify your design through the lesson's principles.
Reflect. In your own words, explain the authorization's role in the AAA model and the four models (the DAC, the MAC, the RBAC, the ABAC), and describe the access control matrix and its two implementations (the ACLs and the capabilities). Then describe one situation in your own experience — a system you have administered or used — where the authorization's design affected the security or the manageability. What was the system, and how would a different model or mechanism have changed the outcome?

10 Summary

The authorization is the AAA model's second pillar: the determination of what an authenticated principal is allowed to do. It follows the authentication (the identity's verification) and precedes the accounting (the actions' recording). Its distinction from the authentication is the security's design's first decision.
The authorization's components are the subjects (the requesters), the objects (the targets), the operations (the actions), and the permissions (the decisions' units). Their definition determines the policy's granularity.
The access control matrix is the authorization's central abstraction: the subjects as the rows, the objects as the columns, and the permissions as the entries. Its two implementations are the access control lists (the columns: the object-centric, the easy's revocation and review) and the capabilities (the rows: the subject-centric, the natural's delegation).
The discretionary access control (the DAC) lets the objects' owners determine the permissions (the permissions' bits, the ACLs). It is the flexible and the simple, but it does not control the information's flow and it burdens the administration. The mandatory access control (the MAC) lets the system's policy determine the access (the security labels, the Bell-LaPadula and the Biba models). It is the rigorous and the centralized, but it is the rigid and the administration is complex.
The role-based access control (the RBAC) determines the access through the subjects' roles. Its components are the users, the roles, the permissions, the sessions, and the constraints. It is the manageable and the organizational, but its roles' explosion limits the scalability and its static's nature limits the context-dependence. The attribute-based access control (the ABAC) determines the access through the attributes of the subjects, the objects, the operations, and the environment. It is the expressive and the context-aware, but its complexity limits the verification and its attributes' management is the burdensome.
The authorization's mechanisms are the permissions' bits (the simple's DAC), the access control lists (the granular's DAC), the capabilities (the subject-centric's), the security labels (the MAC's), and the role's assignments (the RBAC's).
The policy's specification (the what: the subjects, the objects, the operations, the permissions) and the enforcement (the how: the reference monitor, the kernel's checks) are the authorization's design's two halves, and their correspondence is the authorization's correctness's condition.
The principle of least privilege requires the minimum's privileges; the separation of duties requires the multiple subjects for the critical tasks; the delegation and the revocation are the authorization's lifecycle's concerns. The authorization's design applies the Lesson 12.1's principles.

Looking ahead

This lesson presented the authorization: the AAA model's second pillar, the components, the access control matrix and its implementations, the four models (the DAC, the MAC, the RBAC, and the ABAC), the mechanisms, the policy's specification and enforcement, and the design principles. It referred several times to the access control models — the Bell-LaPadula, the Biba, the RBAC's formalization, the ABAC's — and to the access control's mechanisms. Lesson 12.4 presents the access control models in detail: the formal's models (the Bell-LaPadula, the Biba, the Clark-Wilson, the Harrison-Ruzzo-Ullman), the RBAC's formalization (the RBAC0 through the RBAC3), the ABAC's framework (the NIST SP 800-162), the models' comparison, and the models' applications. The lesson is the fourth's pillar of the unit's presentation of the operating system's security, and it is the formal's foundation for the Linux security that Lesson 12.5 presents.

11 References

Silberschatz, A., Galvin, P. B., & Gagne, G. Operating System Concepts, 10th ed., Chapter 16 and 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.
Saltzer, J. H., & Schroeder, M. D. The Protection of Information in Computer Systems. Proceedings of the IEEE, 1975.
Sandhu, R. S., Coyne, E. J., Feinstein, H. L., & Youman, C. E. Role-Based Access Control Models. IEEE Computer, 1996.
Ferraiolo, D. F., & Kuhn, D. R. Role-Based Access Controls. Proceedings of the 15th National Computer Security Conference, 1992.
Hu, V. C., Ferraiolo, D. F., & Kuhn, D. R. Guide to Attribute Based Access Control (ABAC) Definition and Considerations. NIST SP 800-162, 2014.
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.
Linux man-pages: man 1 chmod, man 1 chown, man 1 chgrp, man 1 umask, man 1 setfacl, man 1 getfacl, man 5 acl, man 7 capabilities, man 8 setcap, man 1 getcap, man 5 sudoers, man 8 sudo, man 8 selinux, man 8 semanage, man 8 chcon, man 8 aa-status, man 5 apparmor.d, man 1 id, man 1 stat.