04 Access Control - Chunk 01 (s.1-28)

Overview

Chapter 4 (Stallings and Brown, slides by Lawrie Brown; the file is the “Modified” version) defines access control as “the prevention of unauthorized use of a resource, including the prevention of use of a resource in an unauthorized manner” (s.2). It lays out the three policy families, DAC, MAC and RBAC (s.4-7), the requirements for a good access control system (s.8-9), the basic elements subject, object, access right (s.10-11), the access matrix and how it is extended and enforced (s.12-19), and finally role-based access control with the four reference models RBAC0-RBAC3 (s.20-27). Your own class notes for this chapter add the “rule-based” fourth model and Active Directory; those are not on the slides (see Added Context - Topics Mentioned but Not on the Slides). Quiz style: Past Exam - Question Bank & Style Guide.

Detailed notes

1. Access control basics (s.2-3)

• Central element of computer security (s.2). Assumes users and groups that authenticate to the system and are assigned access rights to certain resources (s.2). See Concept - Access Control.
• Figure s.3: the authentication function verifies the user, then the access control function consults the authorization database (managed by the security administrator) before the user reaches system resources; auditing monitors the whole path.

2. Access control policies (s.4-7)

An access control policy, “embodied in an authorization database”, dictates what types of access are permitted, under what circumstances and by whom (s.4). Three categories:

Policy	Based on	Why named so	Notes
DAC discretionary (s.4)	identity of the requestor and access rules (authorizations)	an entity may, by its own volition, enable another entity to access a resource	the traditional method (s.6)
MAC mandatory (s.5)	comparing security labels (sensitivity/criticality of resources) with security clearances (eligibility of entities)	an entity with clearance may not, by its own volition, enable another entity to access the resource	evolved from military requirements, best covered with trusted systems (s.6); US Government classes: TOP SECRET, SECRET, CONFIDENTIAL, UNCLASSIFIED (s.5)
RBAC role-based (s.6)	the roles users have in the system and rules stating what accesses are allowed to users in given roles	n/a	”increasingly popular” (s.6)

• One may employ two or even all three policies to cover different classes of system resources (s.6). Venn diagram (s.7) shows three overlapping circles. See Concept - Discretionary Access Control, Concept - Mandatory Access Control, Concept - Role-Based Access Control.

3. Access control requirements (s.8-9)

• Reliable input: it assumes that a user is authentic (s.8).
• Support fine and coarse specifications (s.8): fine-grained = access regulated at the level of individual fields/records in files; coarse-grained (slide spells “Course-grained”) = administrators choose broad specifications for some classes of resource accesses.
• Least privilege (s.8): each system entity gets the minimum system resources and authorizations needed to do its work; limits damage from an accident, error or unauthorized act. See Concept - Least Privilege.
• Open and closed policies (s.9): a closed policy only allows accesses specifically authorized (“most useful and most used”); an open policy allows all accesses except those expressly prohibited (“useful in some applications”). See Concept - Open and Closed Policies.
• Administrative policies (s.9): specify who can add, delete or modify authorization rules; they also need access control and other control mechanisms to enforce them.

4. Access control elements (s.10-11)

• Subject (s.10): entity that can access objects; a process representing a user/application; often three classes: owner, group, world.
  • Owner: may be the creator of a resource such as a file; for system resources ownership may belong to a system administrator; for project resources a project administrator or leader may be assigned ownership.
  • Group: in addition to the owner’s privileges, a named group of users may be granted access rights, and membership in the group is sufficient to exercise them.
  • World: the least access is granted to users who can access the system but are not in owner or group for this resource.
• Object (s.11): access-controlled resource, e.g. files, directories, records, programs; number/type depend on the environment.
• Access right (s.11): the way in which a subject accesses an object, e.g. read, write, execute, delete, create, search.
• See Concept - Access Control Elements.

5. Discretionary access control: the access matrix (s.12-17)

• Often provided using an access matrix (s.12): subjects in one dimension (rows), objects in the other (columns), each entry gives the subject’s rights to that object. The matrix is often sparse and can be decomposed by row or by column (s.12).
• Figure s.13 (“Access Control Structures”) shows an access matrix and capability lists; see the worked table below. The slide’s summary mentions “access control lists (ACLs), capability tickets” (s.28), but only the capability list is drawn. (Added context: the row = capability list, column = ACL mapping is the standard textbook reading; the slides only say the matrix can be decomposed by row or column and name ACLs in the summary.)
• Extended access control matrix (s.14-16): objects now include subjects, files, processes and disk drives. Access rights per object type:
  • Processes: delete a process, stop (block), wakeup (s.15).
  • Devices: read/write the device, control its operation (e.g. a disk seek), block/unblock the device for use (s.15).
  • Memory locations or regions: read/write certain locations or regions; protected so that the default is that access is not allowed (s.15).
  • Subjects: ability to grant or delete access rights of that subject to other objects (s.16). A separate access control module is associated with each object type.
  • Copy flag (*): allows grant (delegation), either with or without delegation of the copy flag (s.16). See Concept - Access Matrix and Concept - Copy Flag and Transfer Rules.
• Transfer {r, r*} on X from S to S’ is allowed if any of these hold (s.17): $A[S,X]=r^{\ast }$ (S has right r on X and the copy flag set); $A[S,X]=\text{"owner"}$ (S owns X); $A[S,X]=r$ and $A[S,S^{\prime }]=\text{"control"}$ (S has right r on X and S created S’).
• Delete {r} on X from S’ is allowed if any of these hold (s.17): $A[S,X]=\text{"owner"}$ or $A[S,S^{\prime }]=\text{"control"}$ (slide prints the second as S[S,S'], a typo).

6. Access control function (s.18-19)

An access attempt triggers these steps (s.18):

1. A subject $S_0$ issues a request of type $\alpha$ for object $X$.
2. The request causes the system (operating system or an access control interface module) to generate a message $(S_0,\alpha ,X)$ to the controller for $X$.
3. The controller checks the access matrix $A$ to determine if $\alpha$ is in $A[S_0,X]$. If so the access is allowed; if not, the access is denied and a protection violation occurs.

Figure s.19 shows the mechanisms in detail. See Concept - Access Control Function.

7. Role-based access control (s.20-27)

• RBAC vs DAC (s.21): traditional DAC defines access rights of individual users and groups; RBAC is based on the roles users assume rather than identity; rights are assigned to roles; users are assigned to roles by responsibilities; the user-to-role relationship is many to many.
• Figures s.20, 22, 23: users to roles to resources; a user-role matrix (users x roles with X marks) and a role-object matrix (roles x objects, same layout as the extended matrix); the RBAC model diagram (see Figures).
• RBAC reference models (s.24):

Model	Contains
RBAC0	the minimum functionality for an RBAC system (base model)
RBAC1	RBAC0 + role hierarchies (one role inherits permissions from another)
RBAC2	RBAC0 + constraints (restrict how components may be configured)
RBAC3	RBAC0 + the functionality of both RBAC1 and RBAC2 (consolidated model, s.23)

• RBAC0 entities (s.25): User (an individual with access to the system and an associated user ID), Role (a named job function within the organization, with a description of authority and responsibility), Permission (approval of a particular mode of access to one or more objects; equivalent terms: access right, privilege, authorization), Session (a mapping between a user and an activated subset of the set of roles to which the user is assigned).
• RBAC1 (s.26): job functions with greater authority have greater authority to access resources; role hierarchies use inheritance so one role implicitly includes the access rights of a subordinate role. Example hierarchy (tree drawn on s.26, two branches that converge): Director on top of Project Lead 1 and Project Lead 2; each project lead on top of a Production and a Quality Engineer; both of those on top of Engineer 1 (resp. Engineer 2); Engineer 1 and Engineer 2 both lead down to Engineering Dept. See the diagram in Concept - Role Hierarchy.
• RBAC2 (s.27): a constraint is “a defined relationship among roles or a condition related to roles”. Three types: mutually exclusive roles (a user can be assigned to only one role in the set, during a session or statically; any permission can be granted to only one role in the set), cardinality (a maximum number, e.g. a project leader or department head role limited to one user), prerequisite roles (a user can be assigned a role only if already assigned another specified role, e.g. a project lead must first hold the production engineer and quality engineer roles).
• See Concept - RBAC Reference Models, Concept - RBAC Constraints, Concept - Role Hierarchy.

8. Summary (s.28)

Introduced access control principles (subjects, objects, access rights); discretionary access controls (access matrix, ACLs, capability tickets); UNIX traditional and ACL mechanisms; role-based access control; case study. UNIX and the case study are not in this modified deck (see gaps).

Figures & diagrams

• Access control principles (s.3): user, authentication function, access control function, system resources in a line; the security administrator manages the authorization database linked to the access control function; auditing spans user-to-resources. Takeaway: authentication comes first, authorization (access control) second, and everything is audited.
• Venn diagram of policies (s.7): three overlapping ellipses DAC, MAC, RBAC; overlaps show that policies can be combined for different resource classes (s.6).
• Access matrix and capability lists (s.13): matrix below, rows are subjects, columns are objects.

	File 1	File 2	File 3
User A	Own, Read, Write	(none)	Own, Read, Write
User B	Read	Own, Read, Write	(none)
User C	Read, Write	Read	Read

The slide also draws a capability list for User A: File 1 (Own, Read, Write) and File 2 (Read) with red arrows. Takeaway: capability lists are the row decomposition (per subject); see the error note below.

• Extended access control matrix (s.14): 3 subjects (S1-S3) by 9 objects (subjects S1-S3, files F1 and F2, processes P1 and P2, disk drives D1 and D2); * = copy flag set. Cells:

	S1	S2	S3	F1	F2	P1	P2	D1	D2
S1	control	owner	owner, control	read*	read, owner	wakeup	wakeup	seek	owner
S2		control		write*	execute			owner	seek*
S3			control		write	stop

• Access control function (s.19): subjects $S_i$ (read F), $S_j$ (wakeup P), $S_k$ (grant … to $S_n$, X), $S_m$ (delete … from $S_p$, Y) send requests (S_i, read, F) etc. through system intervention to access control mechanisms (file system, memory addressing hardware, process manager, terminal and device manager, instruction decoding hardware, access matrix monitor) which guard the objects (files, segments and pages, processes, terminal and devices, instructions). The access matrix monitor reads and writes the access matrix. Takeaway: every request is mediated; grant/delete go through the access matrix monitor.
• RBAC users-roles-resources (s.20): four users, three roles, three resources; one user (the monkey) is in two roles, showing many-to-many. Role 1 reaches one document; Role 2 a document and the database; Role 3 all three resources (arrows read from the figure).
• User-role and role-object matrices (s.22): users U1-Um by roles R1-Rn (X marks: U1 R1; U2 R1; U3 R2 and Rn; U4, U5, U6 Rn; Um R1) above a role-by-object matrix with the same cells as s.14.
• RBAC models (s.23, small copy on s.25): (a) lattice: RBAC3 consolidated model on top, RBAC1 (role hierarchies) and RBAC2 (constraints) in the middle, RBAC0 base model at the bottom. (b) Users (U), Roles (R), Permissions (P), Sessions (S): user assignment between U and R, permission assignment between R and P, role hierarchy on R, constraints touching user, roles and permission assignment.
• RBAC1 hierarchy (s.26): tree of boxes (see item 7 above).

Key terms

Concept - Access Control · Concept - Discretionary Access Control · Concept - Mandatory Access Control · Concept - Role-Based Access Control · Concept - Least Privilege · Concept - Open and Closed Policies · Concept - Access Control Elements · Concept - Access Matrix · Concept - Copy Flag and Transfer Rules · Concept - Access Control Function · Concept - RBAC Reference Models · Concept - RBAC Constraints · Concept - Role Hierarchy

Formulas

• Access check: allowed iff $\alpha \in A[S_0,X]$ (s.18); otherwise protection violation.
• Transfer rule: $A[S,X]=r^{\ast }$, or $A[S,X]=\text{"owner"}$, or ($A[S,X]=r$ and $A[S,S^{\prime }]=\text{"control"}$) (s.17).
• Delete rule: $A[S,X]=\text{"owner"}$ or $A[S,S^{\prime }]=\text{"control"}$ (s.17).

Likely exam questions

1. Define access control. “The prevention of unauthorized use of a resource, including the prevention of use of a resource in an unauthorized manner” (s.2).
2. Compare DAC, MAC and RBAC.

	DAC	MAC	RBAC
Basis	requestor identity + access rules	security labels vs clearances	roles of users
Can an entity pass on access by itself?	yes (discretionary)	no (mandatory)	rights come from role assignment
Origin / use	traditional method	military, trusted systems	increasingly popular

(s.4-6) 3. Fill in the blank: giving each entity the minimum resources and authorizations needed to do its work is the principle of ____. least privilege (s.8). 4. Open vs closed policy? Closed only allows accesses specifically authorized (most used); open allows all except those expressly prohibited (s.9). 5. Name the three subject classes. Owner, group, world (s.10). 6. What are the rows and columns of an access matrix, and why is it decomposed? Rows subjects, columns objects, entries rights; it is sparse so it is decomposed by row or by column (s.12); row = capability list (s.13), column = ACL (added context). 7. State the three steps of the access control function. (s.18) Subject issues request; system sends $(S_0,\alpha ,X)$ to the controller of X; controller checks $\alpha \in A[S_0,X]$, allow or deny with protection violation. 8. When may S transfer a right r on X to S’? If S has $r^{\ast }$ on X, or owns X, or has r on X and has control over S’ (s.17). 9. List the four RBAC reference models and what each adds. RBAC0 minimum; RBAC1 role hierarchies; RBAC2 constraints; RBAC3 both (s.24). 10. Name the four RBAC0 entities and the three RBAC2 constraints. User, role, permission, session; mutual exclusion, cardinality, prerequisite roles (s.25, 27). 11. Determine the correctness: “In RBAC, access rights are assigned directly to individual users.” False: RBAC assigns rights to roles and users to roles (s.21).

Added context

Your class notes list a fourth model “Rule-based access control (RBAC, optional)” and the definition “access right is applied on an object”. The first is not on the slides; the slides only treat DAC, MAC, RBAC. Expect the lecturer’s version to match the slides plus those notes.

Common confusions

• DAC vs MAC: DAC lets the owner decide who else gets access; MAC forbids that, access is decided by labels and clearances (s.4-5).
• RBAC abbreviation clash: in your class notes “RBAC” is used for both role-based and rule-based; the slides only use RBAC for role-based (s.6).
• Role vs group: RBAC rights belong to roles; a DAC group is a named set of users with access rights through membership (s.10, 21).
• Subject vs user: a subject is usually a process representing a user/application (s.10).
• Mutual exclusion vs cardinality vs prerequisite: mutual exclusion = cannot hold two roles of the set; cardinality = maximum number of users per role; prerequisite = must already hold another role (s.27).
• Capability list vs ACL: capability list = per subject (row, s.13); ACL = per object (column) (added context, standard reading).

Slide errors and gaps noticed

• s.13: the capability list drawn for User A shows File 1 (Own, Read, Write) and File 2 (Read), but the matrix beside it gives User A no rights on File 2 and Own, Read, Write on File 3. The list should end with File 3 (textbook Figure 4.2); treat it as a slide error.
• s.8: “Course-grained” is a typo for coarse-grained; s.10: “my be assigned”; s.25: “An individuals”.
• s.17: “S[S,S’]” is a typo for $A[S,S^{\prime }]$.
• s.14 and s.22: the second file column is labelled F1 twice in the RBAC figure (s.22 shows F1 F1); on s.14 the second F1 was overwritten with a text box “F2”. Read it as F1 and F2.
• s.28 (summary) names ACLs, capability tickets, UNIX traditional and ACL mechanisms and a case study, but no slides cover UNIX permissions, ACL structures in detail or a case study in this modified deck.

Slide coverage

Slide	Content	Covered in
1	Title: Chapter 4 Access Control (Stallings, Brown)	Overview
2	Access control definition, users and groups	Detailed 1
3	Access control principles figure	Detailed 1, Figures
4	Policies: authorization database, DAC	Detailed 2
5	MAC (labels, clearances, US classes)	Detailed 2
6	RBAC; DAC/MAC/RBAC remarks; combining	Detailed 2
7	Venn diagram of the three policies	Detailed 2, Figures
8	Requirements: reliable input, fine/coarse, least privilege	Detailed 3
9	Open/closed policies, administrative policies	Detailed 3
10	Subject, owner, group, world	Detailed 4
11	Object, access right	Detailed 4
12	DAC and the access matrix	Detailed 5
13	Access matrix + capability lists figure	Detailed 5, Figures
14	Extended access control matrix	Detailed 5, Figures
15	Processes, devices, memory rights	Detailed 5
16	Subjects rights, copy flag	Detailed 5
17	Transfer and delete rules	Detailed 5
18	Access control function steps	Detailed 6
19	Access control function figure	Detailed 6, Figures
20	RBAC users-roles-resources figure	Detailed 7, Figures
21	RBAC vs DAC, many-to-many	Detailed 7
22	User-role and role-object matrices	Detailed 7, Figures
23	RBAC models figure (RBAC0-3 lattice)	Detailed 7, Figures
24	RBAC reference models	Detailed 7
25	RBAC0 entities	Detailed 7
26	RBAC1 role hierarchy	Detailed 7, Figures
27	RBAC2 constraints	Detailed 7
28	Summary	Detailed 8

Previous: 03 User Authentication - Chunk 01 (s.1-33) (previous deck) | Next: 05 Database Security - Chunk 01 (s.1-38) (next deck) | Up: 04 Access Control - Index