Slides prepared based on the paper Access Control: Principles and Practice by Ravi S. Sandhu and Pierangela Samarati, IEEE Communications Magazine, 1994

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

3. The Big Picture

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

13. Access Control Lists

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

17. Capabilities

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

20. Authorization Relations

21. Access Control Policies
 Discretionary policies
 Mandatory policies
 Role-based policies

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

29. Confidentiality Policies

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

32. Integrity Policies

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