Slides prepared based on the paper Access Control: Principles and Practice by Ravi S. Sandhu and Pierangela Samarati, IEEE Communications Magazine, 1994
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
Access Control: Principles and Practice
1. Access Control: Principles
and Practice
Reference: Access Control: Principles and
Practice, Ravi S. Sandhu and Pierangela
Samarati, IEEE Communications Magazine,
1994
Prepared by: Nabeel Mohamed
2. Access Control
The purpose is to limit that the
operations or actions that a legitimate
user of a computer system can perform
Constrains
◦ What a user can do directly, and
◦ What programs executing on behalf of users
are allowed to do
Thus, tries to prevent activities that could
lead to a breach of security
Is required to achieve confidentiality,
integrity and availability objectives
4. The Big Picture
Shows a logical picture of security
services and their interactions
Authentication service should correctly
establish the identity of the user
Authentication, and then Access
Control
Access control is not a complete
solution for securing a system. What is
the missing service?
◦ Auditing
5. The Big Picture
Auditing
◦ Performs a posteriori analysis of all the
requests and activities of users in the system
◦ Requires logging all requests and activities
◦ How can auditing help?
Acting as a deterrent
Identifying attempted or actual violations
Identifying flaws in the security system
Preventing authorized users from misusing their
privileges (accountability)
6. Policies vs. Mechanisms
Policies
◦ High-level guidelines that determine how
accesses are controlled and access
decisions determined
Mechanisms
◦ Low-level software and hardware functions
that can be configured to implement a policy
It is desirable to develop access control
mechanisms that are largely
independent of the policy for which they
could be used
7. The Access Matrix
All resources controlled by a computer
system can be represented by data
stored in objects
Subjects, which initiate activities in the
system, are typically users or programs
executing on behalf of users
Subjects can themselves be objects
Subjects initiate actions on objects
◦ Actions are allowed or denied in accordance
with the authorization established
8. The Access Matrix
Example access rights/modes:
◦ For files, the typical access rights are
read, write, execute and own
OS implements them
◦ For bank accounts, the typical access
rights are inquiry, credit and debit
Application programs implement them
9. The Access Matrix
A conceptual model that specifies the
rights that each subject possesses for
each object
Subjects in rows, objects in columns
10. The Access Matrix
The access matrix model clearly
separates the problem of
authentication from that of
authorization
A reference monitor should ensure
that only those operations authorized
by the access matrix actually get
executed
Example: Alice is the owner of the file
2, and she can read and write that file
11. Implementation Approaches
Access matrix is usually sparse and
hence not implemented as a matrix
Some common approaches to
implementing the access matrix in
practice:
◦ Access Control Lists (ACLs)
◦ Capabilities
◦ Authorization Relations
12. Access Control Lists
Each object is associated with a an
ACL
ACL has an entry of each subject if it
has some kind of access to that object
This approach corresponds to storing
the access matrix by column
14. Access Control Lists
Advantages
◦ By looking at an object’s ACL it is easy to
determine which modes of access
subjects are currently authorized for that
object
◦ Easy to revoke all access to an object
Disadvantages
◦ It is difficult to find all accesses a subject
has
15. Access Control Lists
In order to reduce the list length, the
usual practice is to use groups instead
of (or in addition to) individual subject
identifiers
Example: UNIX getfacl and setfacl
allows to create ACLs on files and
folders
16. Capabilities
A dual approach to ACLs
Each subject is associated with a list
(call the capability list)
A capability list of a subject has a list
of objects for which subject has some
kind of access
18. Capabilities
Advantage
◦ Easy to find all accesses that a subject is
authorized to perform
◦ Easy to revoke all accesses to a subject
Disadvantages
◦ Difficult to find all subjects who have
some kind of access to a given object
Modern operating systems typically
take the ACL-based approach
19. Authorization Relations
Each row or tuple of the authorization
relation specifies one access right of a
subject to an object
For example, John’s accesses to File
1 require 3 rows
If the table is sorted by subjects, it
reflects capabilities
If the table is sorted by objects, it
reflects ACLs
The relation is not normalized
22. Multiple Access Control Policies
AC policies are not exclusive; can be
combined to provide a more suitable
protection system
When policies are combined, only the
intersections of their accesses allowed
23. Discretionary Policies
Access control is under the discretion
of the user
Flexibility of discretionary policies has
made them successful in industry
24. Discretionary Policies
However, they do not provide real
assurance on the flow of information in
the system
◦ It’s easy to bypass the access restrictions
stated through the authorizations
◦ Example: a user, able to read an object, can
pass it to other users with the knowledge of
the owner
◦ The reason is discretionary policies do not
impose any restriction on the usage of
information by a user once the user received
it (dissemination of information is not
controlled)
25. Mandatory Policies
Access control enforcement is under the
control of the system
MLS (Multilevel Security) model is the
most popular mandatory approach
◦ Access is based on the security levels
assigned to objects and subjects
Each user and each object in the system
is assigned a security level
MLS provides one-directional information
flow in a lattice of security labels
26. Mandatory Policies
The security level associated with an
object reflects
◦ The sensitivity of the information
contained in the object
The security level associated with a
subject (also called clearance) reflects
◦ The user’s trustworthiness not to disclose
sensitive information to users not cleared
to see it
27. Example Security Levels
In a military setting we usually find the
following security levels:
◦ Top Secret (TS)
◦ Secret (S)
◦ Confidential (C)
◦ Unclassified (U)
They form the ordered set TS > S > C >
U
Each security level is said to dominate
itself and all others below it in this
hierarchy
28. Confidentiality Policies
Read down
◦ A subject’s clearance must dominate the
security level of the object being read
Write up
◦ A subject’s clearance must be dominated by
the security level of the object being written
Prevent information in high-level objects
(more sensitive) to flow to objects in
lower levels
Information can only flow upwards or
within the same security domain
30. Confidentiality Policies
In order to write at a lower security level,
subject should be allowed to take any
clearance level dominated by its original
clearance level
The intuition behind write-up rule is to
prevent malicious software from leaking
secret information downwards
Write-up rule may destroy data in higher
security levels – Hence, it is usually
controlled to work only at the same
security level as the subject
31. Integrity Policies
Read up
◦ A subject’s integrity level must be dominated
by the integrity level of the object being read
Write down
◦ A subject’s integrity level must dominate the
integrity level of the object being written
Prevent information stored in low objects
(hence less reliable) to flow to high
objects
Protect only one aspect of integrity
Information can only flow downwards or
within the same security level
33. Role-based Policies
Neither discretionary nor mandatory
approaches satisfies the needs of
most commercial enterprises
◦ Mandatory policies rise from rigid
environments, like those of military
◦ Discretionary policies rise from
cooperative yet autonomous
requirements, like those of academic
researchers
One alternative is role-base policies
34. Role-based Policies
The flexibility required:
◦ Allow the specification of authorization to
be granted to users (or groups) on objects
like in the discretionary approach,
together with the possibility of specifying
restrictions (like in the mandatory
approach) on the assignment or on the
use of such authorizations
35. Role-based Policies
A role is a set of actions and
responsibilities associated with a
particular working activity
Instead of specifying all the accesses
each user is allowed to execute, access
authorizations are specified for roles
Users are given authorization to adopt
roles
A user playing a role is allowed to
execute all accesses for which the role is
authorized.
36. Role-based Policies
User may or may not be allowed to
play multiple roles at the same time
A user may take on different roles on
different occasions
37. Advantages of Role-based
Policies
Simplification of authorization
management
Hierarchical roles further simplify by
allowing generalization and
specialization
Adapting different roles to operate at the
least privilege
Promotes separation of duty to prevent
misuse of the system
Instead of individual objects, access can
be specified for object classes
38. Administration of Authorization
Administrative policies determine who
is authorized to modify the allowed
access
In mandatory AC, security
administrator determines the access
to objects by subjects
In discretionary and role-based AC,
there are possibly many types of
administrative policies
39. Administration of Authorization
Example DAC administrative policies
◦ Centralized – a single authorized user like
in MAC
◦ Hierarchical – authorizers are ordered in a
hierarchy with decreasing power
◦ Cooperative – multiple authorizers to
specify each access
◦ Ownership – owner of the object controls
accesses
◦ Decentralized – delegate authorization to
others to control accesses