Operating System Security

and Access Control

Computer Security | Lecture Four

 Lecture Outline
▪ Introduction ▪ The Reference Monitor Concept
▪ Protection Mechanisms ▪ Subject-Object Model
▪ Memory Protection and Isolation ▪ Access Matrix
Mechanisms ▪ Access Control Lists
▪ Memory-Range Based Protection ▪ Capability Lists
▪ Segment Addressing with Access ▪ File-Based Access Control
Permission
▪ FBAC With ACL
▪ Accountability, User-ID and ▪ FBAC with UGO Model
Principals ▪ FBAC with RBAC
 Lecture Outline | Progress
▪ Introduction ▪ The Reference Monitor Concept
▪ Protection Mechanisms ▪ Subject-Object Model
▪ Memory Protection and Isolation ▪ Access Matrix
Mechanisms ▪ Access Control Lists
▪ Memory-Range Based Protection ▪ Capability Lists
▪ Segment Addressing with Access ▪ File-Based Access Control
Permission
▪ FBAC With ACL
▪ Accountability, User-ID and ▪ FBAC with UGO Model
Principals ▪ FBAC with RBAC
 Introduction

▪ 1950s – Mass-produced computers emerged in the.

▪ 1960s – Time-sharing systems brought security
requirements into focus.
▪ 1965-1975 - The golden design age for
▪ Operating system (OS) Protection Mechanisms
▪ Hardware Protection Features
▪ Address Translation
 Introduction
▪ Back then, the Threat Environment was simpler,
▪ Computer networks were largely non-existent
▪ The number of software creators and programs was far smaller
▪ However, the challenges were the same as those we face today,
including
▪ Maintaining Separation of Processes while selectively allowing sharing
of resources
▪ Protecting Programs from others on the same machine
▪ Restricting Access to resources

5
 Lecture Outline | Progress
▪ Introduction ▪ The Reference Monitor Concept
▪ Protection Mechanisms ▪ Subject-Object Model
▪ Memory Protection and Isolation ▪ Access Matrix
Mechanisms ▪ Access Control Lists
▪ Memory-Range Based Protection ▪ Capability Lists
▪ Segment Addressing with Access ▪ File-Based Access Control
Permission
▪ FBAC With ACL
▪ Accountability, User-ID and ▪ FBAC with UGO Model
Principals ▪ FBAC with RBAC
 Protection Mechanisms

▪ “Protection” largely meant ▪ The above are all accessed

controlling access to Memory through Memory Addresses and
Locations Files.
▪ Files are logical units of data in
▪ Since Both Data and Programs primary memory and secondary
are stored in memory. storage
▪ Protection means controlling ▪ Access Control to Memory and
access to Files provides a general basis
▪ Running processes for Access Control of Objects
▪ Input/Output Devices and Devices.
▪ Communications Channels

7
 Protection Mechanisms

▪ Initially, Protection meant limiting the memory addresses

accessible to processes
▪ Early Virtual Memory Address Translation and Access Control Lists
(ACL) were developed to enable Resource Sharing.
▪ These remained the Protection Fundamentals.
▪ Learning about such protection in Operating Systems provides a
another solid basis for understanding computer security.

8
 Lecture Outline | Progress
▪ Introduction ▪ The Reference Monitor Concept
▪ Protection Mechanisms ▪ Subject-Object Model
▪ Memory Protection and Isolation ▪ Access Matrix
Mechanisms ▪ Access Control Lists
▪ Memory-Range Based Protection ▪ Capability Lists
▪ Segment Addressing with Access ▪ File-Based Access Control
Permission
▪ FBAC With ACL
▪ Accountability, User-ID and ▪ FBAC with UGO Model
Principals ▪ FBAC with RBAC
 Memory Protection
▪ Early computers were large and expensive—and simple
compared to later systems
▪ Used to run Single Programs one after the other
▪ Delay between runs wasted valuable computer time
▪ This motivated Batch Processing
▪ Batch Processing: Programs prepared ahead of time were submitted
together as a “batched” job run by an operator.
▪ This reduced idle CPU time and costs, but inconvenienced users

10
 Memory Protection
▪ The Time-sharing Systems of between which the CPU
alternated.
the early 1960s offered an
▪ This is How single-user
alternative for shared use i.e. computers work today – A user
▪ Gave the impression of running running many programs
a program on their own machine Concurrently on a Machine
in real time. ▪ Security issues arise when
▪ Programs appeared to run more than one process runs
Concurrently,
“Concurrently”
▪ However, the innovation was to
organize them as processes ▪ i.e. Resource Conflicts

11
 Isolation Mechanisms
▪ An early concern was with the ▪ If a user process could access the
Computer Memory computer’s full memory range,
errors might disrupt OS Data or
▪ An Isolation Mechanism was Program
needed ▪ Even for computers running single
▪ To prevent one process writing into programs one at a time
another’s memory ▪ There are 2 main Isolation
▪ To avoid errors in one program Mechanisms
impacting another
▪ Memory-Range Based Protection
▪ Such Errors may also come from
Malicious Programs ▪ Segment Addressing with Access
Permission

12
 Lecture Outline | Progress
▪ Introduction ▪ The Reference Monitor Concept
▪ Protection Mechanisms ▪ Subject-Object Model
▪ Memory Protection and Isolation ▪ Access Matrix
Mechanisms ▪ Access Control Lists
▪ Memory-Range Based Protection ▪ Capability Lists
▪ Segment Addressing with Access ▪ File-Based Access Control
Permission
▪ FBAC With ACL
▪ Accountability, User-ID and ▪ FBAC with UGO Model
Principals ▪ FBAC with RBAC
 Isolation Mechanisms
Memory-Range Protection Mechanism
▪ All memory references go through a Supervisor Program, which runs with a
hardware Descriptor Register holding Privileged Bit set could load the
a Memory Descriptor consisting of a Descriptor Register.
(base, bound) pair of values. ▪ User programs could set Privileged Bit
▪ Base = Lowest physical memory only via a machine instruction that
address accessible to the active immediately transferred execution to
process the Supervisor Program.
▪ Bound = Number of addressable ▪ This Design protect Memory
memory words from that point Descriptors by storing them in
▪ To control the memory address range memory managed exclusively by the
visible to a process, only the Supervisor.

14
15
 Isolation Mechanisms
Memory-Range Protection Mechanism
▪ This Process Isolation consist ▪ Must be set for the Descriptor
Register to be loaded.
of a simple 3-component
▪ Only supervisor code runs with
memory protection scheme this bit set.
▪ Descriptor Register ▪ Supervisor
▪ Constrains the addresses a ▪ No other program can alter the
process can access. privileged bit.
▪ The Supervisor maintains a ▪ A special machine instruction
descriptor for each process and can also set the bit and
loads this register for the active immediately transfer control to
process. the Supervisor
▪ Privileged Bit:

16
 Isolation Mechanisms
Memory-Range Protection Mechanism
▪ In this memory Protection scheme,
▪ The Supervisor prevents user processes from altering supervisor code
or data by reserving memory that user processes cannot access.
▪ This provides an all-or-nothing mode in the sense of full access to
everything as Supervisor, or no cross-process sharing at all.
▪ Limitation:
▪ This allows full ISOLATION, but not fine-grain Sharing of Memory
▪ The next step forward is more specific Access Permissions
▪ Allowing separate Read, Write and Execute permissions for a specified
memory region

17
 Lecture Outline | Progress
▪ Introduction ▪ The Reference Monitor Concept
▪ Protection Mechanisms ▪ Subject-Object Model
▪ Memory Protection and Isolation ▪ Access Matrix
Mechanisms ▪ Access Control Lists
▪ Memory-Range Based Protection ▪ Capability Lists
▪ Segment Addressing with Access ▪ File-Based Access Control
Permission
▪ FBAC With ACL
▪ Accountability, User-ID and ▪ FBAC with UGO Model
Principals ▪ FBAC with RBAC
 Isolation Mechanisms
Segment Addressing With Access Permissions
▪ A Memory Segment is a continuous block of words, representing
a logical unit of information.
▪ A memory word is then addressed by a pair of values (S, W)
▪ The segment number S and word number offset W afterwards.
▪ Thus a separation of this early Virtual Memory Descriptor from a
Segment’s Physical Address.
▪ The OS maintains a special per-process descriptor segment that
holds a Table of Segment Descriptors defining the Physical
Memory addressable by the process.
19
 Isolation Mechanisms
Segment Addressing With Access Permissions
▪ The addressing scheme controls access—
▪ A process can’t access a segment that it can’t “see”
▪ A Processor Descriptor Base Register (DBR) points to the Descriptor
Segment of the Active Process
▪ S is an index in this table, and each Segment Descriptor contains details
of a segment’s
▪ Physical starting address
▪ Current size
▪ An Access Control Indicator specifying Permission Bits for this memory
segment

20
 Isolation Mechanisms
Segment Addressing With Access Permissions
▪ Access Control Indicators ▪ if 1, segment is Executable;
▪ R: Read ▪ Usually then W=0, code not self-
modifying
▪ if 1, a non-supervisor process
has Read access; ▪ M: Mode
▪ if 0, only the Supervisor does ▪ if 1, Supervisor mode when
executing segment;
▪ W: Write
▪ Valid only when X=1
▪ if 1, the segment may be written
into; ▪ F: Fault
▪ Usually then X=0 ▪ if 1, all access attempts trap to
Supervisor;
▪ X: Execute
▪ Overrides all other bits

21
22
 Lecture Outline | Progress
▪ Introduction ▪ The Reference Monitor Concept
▪ Protection Mechanisms ▪ Subject-Object Model
▪ Memory Protection and Isolation ▪ Access Matrix
Mechanisms ▪ Access Control Lists
▪ Memory-Range Based Protection ▪ Capability Lists
▪ Segment Addressing with Access ▪ File-Based Access Control
Permission
▪ FBAC With ACL
▪ Accountability, User-ID and ▪ FBAC with UGO Model
Principals ▪ FBAC with RBAC
 Accountability, User-ids and Principals
▪ Each user account on a system Accountable for the process
has a username mapped by the ▪ The UID is the primary basis for
OS to a numeric userid (UID). granting access privileges
▪ Users enter Username + Password ▪ UID also serves
to log in ▪ Administrative and billing purposes,
▪ Principal: ▪ Aids debugging,
▪ “Entity” responsible for code ▪ Audit trails,
execution resulting from user (or ▪ Forensics.
consequent program) actions. ▪ A separate process identifier (PID)
▪ The OS associates a UID with each is used for OS-internal purposes
process
such as scheduling
▪ This identifies the Principal

24
 User Roles

▪ A User may function in several Roles,

▪ e.g., as a Regular User and occasionally as an Administrator.
▪ By the principle of Least-Privilege
▪ Common practice is to assign the user more than one username, and
switch usernames (thus UIDs internally) when acting in a role requiring
the privileges of a different domain;
▪ Abstractly, distinct UIDs are considered distinct Principals.
▪ Use of the same username by several users is generally frowned upon as
poor security hygiene, hindering Accountability among other drawbacks

25
 Lecture Outline | Progress
▪ Introduction ▪ The Reference Monitor Concept
▪ Protection Mechanisms ▪ Subject-Object Model
▪ Memory Protection and ▪ Access Matrix
Isolation Mechanisms ▪ Access Control Lists
▪ Memory-Range Based ▪ Capability Lists
Protection ▪ File-Based Access Control
▪ Segment Addressing with
▪ FBAC With ACL
Access Permission
▪ FBAC with UGO Model
▪ Accountability, User-ID and
▪ FBAC with RBAC
Principals
 The Reference Monitor Concept

▪ Proposed in 1972 as a model for building secure systems

for government use in the context of defending against
malicious users.
▪ The basic notion was stated thus:
▪ All references by any program to any program, data or device are
validated against a list of authorized types of reference based on
user and/or program function.

27
 Reference Monitor Dependencies

▪ In addition to properly functioning reference validation

mechanism, the reference monitor depends on:
▪ A trustworthy authentication system
▪ The access matrix assumes legitimate identified subjects
▪ Properly Operating Hardware,
▪ Physical Security of this Hardware and System
▪ including Storage Media and any devices accessing memory
▪ Security of the input-output communication paths between users and
the system.

28
29
 The Reference Monitor Concept

▪ The Reference Monitor is a Subject-Object Model.

▪ A Subject (or Principal) is a system entity that may request access to
a system object.
▪ An Object is any item that a subject may request to use or alter—e.g.,
▪ Active processes, Memory addresses or segments, Code and data
▪ Pages in main memory, swapped pages, files in secondary memory
▪ Peripheral devices such as terminals and printers
▪ Often involving input/output, memory or media
▪ Privileged instructions.

30
 Lecture Outline | Progress
▪ Introduction ▪ The Reference Monitor Concept
▪ Protection Mechanisms ▪ Subject-Object Model
▪ Memory Protection and Isolation ▪ Access Matrix
Mechanisms ▪ Access Control Lists
▪ Memory-Range Based Protection ▪ Capability Lists
▪ Segment Addressing with Access ▪ File-Based Access Control
Permission
▪ FBAC With ACL
▪ Accountability, User-ID and ▪ FBAC with UGO Model
Principals ▪ FBAC with RBAC
 Subject-Object Model
▪ A System first identifies all Subjects and Execute for code
Objects. ▪ The authorization of privileges across
▪ For each Object, the types of access subjects and objects is modeled as an
(Access Attributes) are determined Access Control Matrix
▪ Each corresponds to an Access ▪ Rows = Subjects
Permission or Privilege. ▪ Columns = Objects
▪ Then for each Subject-Object pair, the ▪ Indexes (i, j) = Access Control Entries
system predefines the Authorized (ACE)
Access Permissions of that Subject to ▪ Specifying access permissions Subject i
that Object has to Object j
▪ Examples of types of access are Read or ▪ ACE will typically contain a collection of
Write for a data item or memory address, Permissions

32
33
 Lecture Outline | Progress
▪ Introduction ▪ The Reference Monitor Concept
▪ Protection Mechanisms ▪ Subject-Object Model
▪ Memory Protection and Isolation ▪ Access Matrix
Mechanisms ▪ Access Control Lists
▪ Memory-Range Based Protection ▪ Capability Lists
▪ Segment Addressing with Access ▪ File-Based Access Control
Permission
▪ FBAC With ACL
▪ Accountability, User-ID and ▪ FBAC with UGO Model
Principals ▪ FBAC with RBAC
 Access Matrix
▪ Access Control is often ▪ Several problems with a
implemented by Storing Straightforward Implementation.
Permissions within Access ▪ Typically, number of subjects
and objects will be very large.
Matrix Entries in lists organized
▪ Most entries in the matrix will
either by Rows or Columns be either blank or the same
▪ Access Matrix is merely a ▪ Creation and Deletion of
theoretical model Subjects and Objects will
▪ Implementing an array and the require the matrix to be
commands to manipulate the managed carefully
array – a system mechanism to ▪ Adding to the complexity of
control access to Objects this code

35
 Managing Complexity of Access Matrix

▪ Several optimizations enable systems to use more

convenient, and in some cases simpler, versions of the
Access Control Matrix
▪ For Example
▪ Access Control Lists
▪ Capabilities
▪ 📝To Study: Ring-based Mechanism
▪ 📝To Study: Locks and Keys, is based on Cryptography

36
 Lecture Outline | Progress
▪ Introduction ▪ The Reference Monitor Concept
▪ Protection Mechanisms ▪ Subject-Object Model
▪ Memory Protection and Isolation ▪ Access Matrix
Mechanisms ▪ Access Control Lists
▪ Memory-Range Based Protection ▪ Capability Lists
▪ Segment Addressing with Access ▪ File-Based Access Control
Permission
▪ FBAC With ACL
▪ Accountability, User-ID and ▪ FBAC with UGO Model
Principals ▪ FBAC with RBAC
 Access Control Lists
▪ Store each Column with the Object it
represents
▪ Decomposition by fixed column j∗ puts the
focus on an individual object;
▪ Thus, each object has associated with it a
set of pairs, with each pair containing a
subject and a set of rights.
▪ The named Subject can access the
associated Object using any of those rights
38
 Capability-Lists

▪ Conceptually, a capability is like the

Row of an access control matrix.
▪ Each Subject has associated with it a set of
pairs, with each pair containing an object
and a set of rights.
▪ The Subject associated with this list can
access the named Object in any of the
ways indicated by the named rights.

39
 Lecture Outline | Progress
▪ Introduction ▪ The Reference Monitor Concept
▪ Protection Mechanisms ▪ Subject-Object Model
▪ Memory Protection and Isolation ▪ Access Matrix
Mechanisms ▪ Access Control Lists
▪ Memory-Range Based Protection ▪ Capability Lists
▪ Segment Addressing with Access ▪ File-Based Access Control
Permission
▪ FBAC With ACL
▪ Accountability, User-ID and ▪ FBAC with UGO Model
Principals ▪ FBAC with RBAC
 Object Permissions and
File-based Access Control

▪ After specifying Subjects and Objects in the Subject-Object

Model,
▪ The task is to identify the types of access operations (modes) for
objects and frame these as permissions for consideration

41
 File-Based Access Control

▪ A common approach to learn about object-level access

permissions is to consider Logical Files in Unix Systems
▪ Beyond a file’s data contents, filesystems maintain per-file
meta-data specifying access permissions.
▪ In Unix, an early design principle was to treat everything as a File,
and design a corresponding Filesystem;
▪ This simplifies input-output operations across a multitude of peripheral
devices

42
 File-based Access Control
File Owner and Group
▪ In Unix each file is assigned an with UID=0;
Owner and a Protection Group, ▪ Such a process is granted access to
all file resources, independent of
▪ Respectively identified as a userid protection settings.
(UID) and a groupid (GID).
▪ The username conventionally
▪ Initial values are set on File Creation associated with UID=0 is “root”
▪ Other than for login, the system ▪ but technically the string “root”
uses UID for access control, not could be assigned to other UIDs.
username ▪ Therefore the UID value of 0
determines permissions, not the
▪ Superuser and Root string name
▪ Superuser means a process running

43
 Lecture Outline | Progress
▪ Introduction ▪ The Reference Monitor Concept
▪ Protection Mechanisms ▪ Subject-Object Model
▪ Memory Protection and Isolation ▪ Access Matrix
Mechanisms ▪ Access Control Lists
▪ Memory-Range Based Protection ▪ Capability Lists
▪ Segment Addressing with Access ▪ File-Based Access Control
Permission
▪ FBAC With ACL
▪ Accountability, User-ID and ▪ FBAC with UGO Model
Principals ▪ FBAC with RBAC
 File-Base Access Control with ACL
▪ Operating systems commonly time;
now support ACLs for system ▪ ACLs may need frequent
objects including files. updates;
▪ Listing all Principals requiring
▪ ACLs are powerful and offer
access to a file can be tedious.
fine-grained precision— but
▪ Alternatives to ACL
also have disadvantages.
▪ UGO Model (less Expressive),
▪ ACLs can be as long as the list
of system Principals ▪ Role-Based Access Control
▪ Consuming memory and search
(RBAC)

45
 Lecture Outline | Progress
▪ Introduction ▪ The Reference Monitor Concept
▪ Protection Mechanisms ▪ Subject-Object Model
▪ Memory Protection and Isolation ▪ Access Matrix
Mechanisms ▪ Access Control Lists
▪ Memory-Range Based Protection ▪ Capability Lists
▪ Segment Addressing with Access ▪ File-Based Access Control
Permission
▪ FBAC With ACL
▪ Accountability, User-ID and ▪ FBAC with UGO Model
Principals ▪ FBAC with RBAC
 FBAC with User-Group-Others (UGO) Model

▪ The UGO Permission Model assigns privileges based on three

categories of principals: (User, Group, Others).
▪ User = refers to the principal that is the file owner.
▪ Group = enables sharing of resources among small sets of users with
relatively simple permissions management.
▪ E.g. Project groups
▪ Others = Universal group for “everyone else”.
▪ It defines permissions for all users not addressed by the first two categories
▪ Means to grant non-empty file permissions to users who are neither the file
owner nor in the file’s group

47
 Access Control List Vs
User-Group-Others Model
▪ UGO provides a compact and efficient way to handle an object
for which many (but not all) users should be given the same
privileges.
▪ This UGO model allows fixed-size filesystem meta-data entries, and
saves storage and processing time.
▪ The Permission checking involves bit-operations on sets of just three
categories of principals;
▪ UGO’s downside is a significant loss in expressiveness.
▪ Whereas ACLs may involve arbitrary-length lists,
▪ Upside = Greater expressiveness

48
 UGO | Meta-Data and File Permission
▪ The UGO mechanism is supported ▪ Group = Groupid (GID) of the file.
by a per-file filesystem data ▪ 9 bits: 3 protection bits for each of
structure, (user, group, others).
▪ For regular files, meaning:
▪ This Data structure holds other
“accounting details” related to a file, ▪ R (read): Read file content
such as the address of the file ▪ W (write): Existing file’s content
may be modified.
contents.
▪ X (execute): a binary file may be
▪ The data structure contains the run. R+X to run a shell script.
following protection-related fields ▪ 3 bits: special protection bits setuid,
▪ User = Userid (UID) of file owner. setgid, t-bit

49
50
 UGO | Use Of Protection Bits

▪ When a user process requests access to a file,

▪ The system checks whether the process has the requested access
privilege,
▪ The check is based on the permissions in this data structure.
▪ The checks are made in sequence: User → Group → Others.
▪ The first qualifying category determines privileges.
▪ For a process that seeks R access and is the file owner, if the user
category does not grant R, the request fails even if others grants R.

51
 UGO | Permission Display Notation
▪ A common visual display format for file permissions is a 10-
character string, such as -rwxr-xr--
▪ The first character conveys File type
▪ a leading dash indicates a non-directory file.
▪ The next Nine characters, in groups of Three, convey Permissions for the
UGO categories in order.
▪ A substring rwx corresponds to binary 111
▪ indicating Read, Write and Execute,
▪ A dash “-” conveys a 0-bit denoting that the corresponding permission is
absent.

52
53
 Lecture Outline | Progress
▪ Introduction ▪ The Reference Monitor Concept
▪ Protection Mechanisms ▪ Subject-Object Model
▪ Memory Protection and Isolation ▪ Access Matrix
Mechanisms ▪ Access Control Lists
▪ Memory-Range Based Protection ▪ Capability Lists
▪ Segment Addressing with Access ▪ File-Based Access Control
Permission
▪ FBAC With ACL
▪ Accountability, User-ID and ▪ FBAC with UGO Model
Principals ▪ FBAC with RBAC
 Mandatory and Discretionary Access Control

▪ Access Control policy rules are have to every object

enforced by the Operating ▪ E.g. the Multi-Level Security
model of the US DoD assigns
System security clearance level, and
correspondingly classifies
▪ Discretionary Access Control documents: Top Secret,
▪ Resource owner has the Secret, Confidential, Controlled
discretion as to what Unclassified, Unclassified
permissions to grant others ▪ In M-AC and D-AC permissions
regarding
are assigned based on subject
▪ Mandatory Access Control
identity (userid).
▪ A security policy administrator
defines permission subjects

55
 FBAC with Role-Based Access Control (RBAC)

▪ The idea of Role-based Access Control is that a user, represented

as a Subject, is assigned one or more Roles in each active
session.
▪ Each Role is pre-assigned a set of permissions.
▪ A Subject’s current roles then determine its permissions.
▪ This reflects how permissions are often assigned in larger
organizations (enterprises).
▪ Roles may be Hierarchically defined,
▪ E.g., so that a SeniorManager role is the union of all roles enjoyed by
junior managers, plus some roles specific to the higher position.

56
 Role-Based Access Control (RBAC)

▪ RBAC System Administrators make design choices as to

which tasks (and corresponding permissions) are
associated with different job functions and define roles
accordingly.

57
 Example | RBAC
▪ GradAdmin has read and write access to department files related
to current students, new applicants, and office supply budgets
▪ GrantManager has read access to files for department member
grants.
▪ A new staff member Alex who is assigned both these roles will then
acquire both sets of permissions.
▪ When Alex moves to another department and Corey takes over, Corey
gets the same permissions by being assigned these two roles;
▪ If individual file-based permissions were used, a longer list of
individual permissions might have to be reassigned.
58
 Role-Based Access Control Vs
Access Control List
▪ For most business applications, RBAC is superior to ACL in
terms of security and administrative overhead.
▪ ACL is better suited for implementing security at the individual user
level and for low-level data
▪ E.g. An ACL can grant Write access to a specific file, but it cannot
determine how a user might change the file
▪ RBAC better serves a company-wide security system with an
overseeing Administrator.

59
 📝 To Study

▪ File Permissions for

▪ Directory Files
▪ Non-Directory Files
▪ Soft and Hard Links and the effect of File Delete

60
 Lecture Outline | End
▪ Introduction ▪ The Reference Monitor Concept
▪ Protection Mechanisms ▪ Subject-Object Model
▪ Memory Protection and Isolation ▪ Access Matrix
Mechanisms ▪ Access Control Lists
▪ Memory-Range Based Protection ▪ Capability Lists
▪ Segment Addressing with Access ▪ File-Based Access Control
Permission
▪ FBAC With ACL
▪ Accountability, User-ID and ▪ FBAC with UGO Model
Principals ▪ FBAC with RBAC