CPSC 506

Computer Security I
<MEETING TIME AND INSTRUCTOR>
WEEK 2

1
Review: User Authentication
Definition and goals of user authentication
Implementation of password-based authentication
◦ Secure password selection
◦ Hashes and salt

Multi-factor and Challenge/response authentication

◦ How can they potentially provide higher confidence?

Token-based authentication
◦ Attributes needed for a secure token
◦ Potential advantages compared with password-based authentication
◦ Compare/contrast memory card and smart card as tokens

Biometric authentication
◦ Potential strengths and weaknesses compared to other methods

2
Access Control (Ch. 4)

3
Two fundamental types of defense
User Authentication: who can use the system and its resources
◦ Think “logging in”, but in a broader context: user proves identity

Access Control: what users are allowed to do (data they may access and actions they may
perform)
◦ Key term: “permissions”

4
Access Control – official definition
RFC 4949, Internet Security Glossary: Access control is a process by which use of system
resources is regulated according to a security policy and is permitted only to authorized users.
◦ Q: Isn’t that a bit broad, then?
◦ A: Yes. “In a broad sense, all of computer security is concerned with access control.” (p. 114)
◦ User authentication could be considered the first step of access control. It’s first step in determining
which resources users can access

We will focus on the operating system level, where access control is mainly about which users
have which permissions to access which system resources.

5
Access Control Paradigms
We’ll discuss four ways researchers have defined for “doing” access control. The distinction will
become clearer as we get into the details.
Discretionary Access Control (DAC):
Users own some resources and have some control over how other users can access them.
◦ The most prevalent, which we’ll spend the most time on

Mandatory Access Control (MAC):

Uses a system of labels and clearances to control access; user’s aren’t allowed to grant privileges
to others
◦ Highly sensitive (military) applications

Role-based Access Control (RBAC): based on roles; not necessarily disjoint from the above two.
Attribute-based Access Control (ABAC): based on attributes and environmental conditions

6
The Fundamental Units of Access
Control
Any element of an Access Control Policy can be expressed in terms of
Subjects, Objects, and Access Rights
Subject: Who is doing it. Examples: process, user, group, application
Object: Who they are doing it to. Examples: file, device, database table, network port
Access Right: The action they are allowed or not allowed to do: Examples: read, write, delete

Writes

Subject (User) Object (file)

7
A prevalent type of access control

What is the subject? What are the objects? What permissions are being asked for?

8
Encoding an Access Control Policy
Imagine writing down every permission given on a system as a subject-rights-object sentence.
Examples:
user perryjn has read, execute permission for file “hello.txt”
group users has read permission for ports 8192-16383
…
The set of all these sentences comprises the system’s access control policy.
Alternatively, the policy could be expressed as a matrix.

9
An Access
Control
Matrix
Subjects are rows,
objects are columns,
permissions are in
the cells.
Implementing Access Control Policies
Most issues in access control relate to how such an access control policy is specified,
represented, stored, accessed, and checked.
How does a given system handle access control? What are the data structures used?
Storing the entire matrix in a centralized location, and checking it before each operation, does
not scale. So there are compromises.
It comes down to different ways of decomposing the matrix.

11
Access Control Lists (1)
If we decompose the policy matrix by columns, storing the set of user permissions for an object
with that object, we have Access Control Lists (ACLs).

12
Access Control Lists (1)
If we decompose the policy matrix by columns, storing the set of user permissions for an object
with that object, we have Access Control Lists (ACLs).

13
Windows uses
ACLs
When you edit permissions
for a file by right-clicking and
selecting properties, then the
Security tab, you are editing
the ACL of that file.
What are the subjects?
Object? Access Rights?
On an NTFS file system, ACLs
are stored in the Master File
Table (MFT)
MacOS X also uses ACLs,
accessible through “Finder Get
Info”
14
Pluses and Minuses of ACLs
For any given file, easy to determine who has what permissions for that file.
◦ All permissions for an object are stored with the object.

Hard to determine which access rights a given user or group has.

◦ Users’ rights information is scattered across all files in the system

Changing permissions for a given user across a large set of objects (such as all files in a
directory) is slow.

What is the alternative way to decompose the access policy matrix?

15
Method 2: Capability Lists
If we decompose the policy matrix by rows, storing permissions with the user, we have what is
known as capability lists.

16
Capability Tickets
Because the nodes of a capability list are associated with a user (subject), and represent a user’s
rights for a particular object, they are called capability tickets.
To access or modify a file, “present your ticket”
If the users have direct access to their own tickets (rather than mediated through the operating
system), the tickets have to be made unforgeable.

17
Pluses and Minuses of Capability Lists
+ For any given user, easy to determine the total set of permissions they have.
◦ Just look at all their tickets.

+ May be good for distributed systems, as objects don’t have to be tracked down and directly
accessed in order to grant or revoke permissions for them.
− Hard to determine who has access rights to a given object.
◦ Rights to a given object are scattered across the system in the form of tickets

− Changing permissions for a given object (file) across many subjects (users) is slow.

Capsicum: a research implementation of Capabilitity Lists for Unix OSes

https://www.cl.cam.ac.uk/research/security/capsicum/

18
Discretionary Access Control (DAC)
If a user is the owner of an object, they can grant and revoke permissions to other users.
This is the essence of Discretionary Access Control.
(Subjects can exercise “discretion” over the permissions of their owned objects.)
Try: Define an owner granting and revoking
permissions in terms of the matrix.
Both ACLs and Capability Lists can be used to
implement DAC.
Try: Describe granting and revoking
in terms of ACLs and Capability
tickets.

19
Unix File Permissions

20
The Unix File Access Control System
Also an example of discretionary access control.
File-based, like ACLs, but considerably more primitive
◦ Doesn’t allow expressing all possibilities of the Access Control Matrix.

21
Unix File Access Control
Three subject categories: User, Group, World (others)
◦ Each file is associated with a user owner and a group owner
◦ Users can belong to multiple groups

File permissions, stored in inode data structures on disk, have bits to indicate read, write, execute
permissions for user, group, and world
drwxr-xr-x 2 perryjn users 4096 Sep 27 2013 bin
drwxr-xr-x 2 perryjn users 4096 Sep 10 13:45 cs220
-rw-r--r-- 1 perryjn users 0 Sep 17 16:06 file.txt
drwx------ 2 perryjn users 4096 Sep 10 11:59 logs
drwxr-xr-x 3 perryjn users 4096 Sep 8 11:52 packages
drwxr-xr-x 2 perryjn users 4096 Sep 7 11:18 public_html
drwxr-xr-x 7 perryjn users 4096 Sep 8 12:00 sysroot
drwxr-xr-x 2 perryjn users 4096 Sep 8 11:59 usr

One all-powerful user, named “root”

22
Unix file permissions versus ACLs
ACL’s are much more flexible than the Unix permissions system
◦ Allows granting any set of rights to any number of users and groups for
any resource.
◦ With Unix file permissions, you get only one rights setting for
one group, one for the owner, and one for others.

-rw-r--r-- 1 perryjn users 0 Sep 17 16:06 file.txt

The usual way to work around this is in Unix to add more and more groups.
◦ A group for each combination of privileges that could be on a file.
◦ Potential violation of secure design principles #5-#7: Separation of Privilege, Least Privilege, Least Common
Mechanism

Actually, modern Unix systems do implement ACLs as an optional extension to file permissions.
On the other hand, because of the flexibility of ACL’s, the complexity of managing permissions can easily
get out of hand. This is also a potential source of security errors.
◦ Potential violation of secure design principle #1: Economy of Mechanism
23
Executable Programs are like subjects
Executable programs are stored as files (objects); but when they run, like subjects, they are able
to take actions and access other files and resources.
How do we assign permissions to programs?
Programs usually run with the permissions of the user who runs them.
◦ This makes sense, because the program shouldn’t be able do anything the user isn’t allowed to do.

However, there are exceptions.

◦ Users may wish to restrict the permissions of programs they do not completely trust.
◦ Users may need to run programs with elevated permissions.
◦ Certain programs may need to run with permissions of a different user than the user who runs them.

24
Example 1: restricting program
permissions

25
Example 2: running a programs at a
higher privilege level
Windows:

26
Example 3: when programs can run with
higher privilege than their user
In Linux, the SUID (setuid) mechanism allows a program to run with the privileges of its owner,
rather than the user running it.
It’s another bit that you set on a file, which shows as an ‘s’ in the directory listing:
-rwsr-xr-x 1 root root 27864 Aug 17 2014 /usr/bin/passwd

In particular, an suid program owned by the root user runs with the privileges of root.
Certain programs need to be setuid to allow ordinary users to interact with the system in limited
ways that they don’t normally have permissions for
◦ Example: printing, rebooting, changing my password
◦ But having such “privileged” executables is a huge source of security problems.

27
Role-based Access
Control
SECTION 4.6

28
The Problem
Subjects (users) have a wide range of different permissions; some
overlapping, some disjoint
Managing this can be a headache, and cause security risks
“Permission creep”: The longer people stay in an
organization, they gradually accumulate more and more
permissions as they are added for various jobs.
◦ These permissions are often not audited or removed
after the job is finished
◦ Users having more permissions than necessary
creates greater risk in case of an accident or break-in

29
Role-based
access control
(RBAC)
Postulates new entities called
roles: Can be thought of as jobs
requiring a given set of
permissions
Rights to access objects are
given to roles instead of
subjects.
Then, subjects (users) can have
roles assigned or removed,
automatically obtaining or
losing all the rights of that role.

30
Role-based
access control
(2)
The goal of role-based access
control is to reduce the
complexity of managing the
relationships between subjects
and objects…
Especially by having the
system’s security mechanisms
correspond more closely to the
real-world organization.

31
Example Roles
Application Software Developer
Project Manager
Accounts Manager The policy for RBAC is specified using two
matrices.
Database Administrator
Web Designer
Website Administrator
Hardware Administrator
HR Administrator

32
RBAC: Role-Object Matrix

33
Subject-Role Matrix
For assigning roles (columns) to subjects (rows)
A many-to-many relationship: subjects can have
multiple roles and roles can have multiple subjects.
When you have multiple roles, your permissions are
the union of the permissions of all your roles.
The Role-Object matrix should be largely static; the
Subject-Role matrix can be changed more frequently.

34
Advantages of Role-based Access
Control
The permissions needed by roles are less likely to change once they are set up.
The assignment of subjects to roles is dynamic and many-to-many, but should map closely to
real-world roles, making management more transparent.
◦ The more closely the system entities map to the real-world entities, the less likely security errors are
to creep in.

Prevents accumulation of rights (permission creep) in users who move through several roles

35
Understanding the difference
Q: How are roles different from subject groups?
A: Groups can be used in the same way that roles are.
◦ However, the group mechanism does not enforce any encapsulation of rights.
◦ Doesn’t prevent creating a big mess of individual user permissions.
◦ Roles completely mediate between subjects and objects to reduce complexity.

36
Role Hierarchies and Inheritance
Roles can be arranged in a hierarchy, so that a higher-level role automatically inherits all the
rights of the roles below it.

What are potential advantages and

disadvantages of this?

37
Real-world deployment of RBAC
Dresdner Bank
◦ Major European bank
◦ At time of deployment, 50,659 employees and 1,459 branches (as of 2000)
◦ About 1300 roles in the system (position/function combinations)

Source: http://www-users.cs.york.ac.uk/~jeremy/papers/SACMAT2001.pdf

38
Attribute-based Access
Control (ABAC)

39
Attribute-Based Access Control (ABAC)
A logic-based system of access control.
The access control policy is, in fact, expressed as a set of written rules
◦ In a logical language e.g. XACML (eXtensible Access Control Markup Language)

Subjects and objects have attributes that describe them.

◦ Attributes of subjects: is-user, is-administrator, is-system-service
◦ Attributes of objects:

The rules are written in terms of these attributes:

“If a subject is the creator of an object and the object is a
file, then the subject has permission to write the object.”
An access request is checked by evaluating any applicable rules to get a yes/no decision.

40
Attribute-Based Access Control (ABAC)
“If a subject is the creator of an object and the object is a
file, then the subject has rights to write the object.”
Without the presence of attributes, rules would have to be expressed in terms of individual
subjects, objects, and subject groups.
Attributes allow rules to be expressed in a general, yet precise, manner.
+ Great expressive power; gives the potential of matching organizational policy even more
closely to the system implementation.
− Slower than a table or list-based system, due to the need for reasoning (deduction).

41
RBAC and ABAC
To simplify the implementation and management of access control policies, RBAC and ABAC add
new abstractions to the access control model, beyond subjects, objects, and rights.
RBAC introduces roles, which allow sets of permissions
corresponding ro real-world roles to be assigned and revoked.

ABAC introduces attributes that describe subjects and

objects, and allow broad and yet specific policies to be
phrased in the form of logical sentences.
◦ “If a subject is the creator of an object
and the object is a file, then the subject
has permission to write the object.”

42
Mandatory Access
Control

43
What is Mandatory Access Control?
In contrast to Discretionary Access Control (DAC), in MAC users cannot grant others permissions.
A different model is typically used to deploy MAC.

44
The Bell-LaPadula formal model for
mandatory access control (10.1)
Hierarchy of security levels, e.g., the US military classification scheme
top secret > secret > confidential > restricted > unclassified
Each subject has a security clearance of a given level
Each object has a security classification ( = label) of a given level
◦ Objects are not only files, but also zones into which data can be written and read

Now, consider the operations of read and write. How should access be limited based on
clearances and labels?
Bell-LaPadula rule 1: “No read up”
Subjects can only read data of their own classification or lower.
Subject Object
clearance Classification
Top Secret Top Secret
Secret Secret
Confidential Confidential
Restricted Restricted
Unclassified Unclassified

This is called the simple security (SS) property.

Bell-LaPadula rule 2: “No write down”
Writing can only be done into a zone with equal or higher classification.
Subject Object
clearance Classification
Top Secret Top Secret
Secret Secret
Confidential Confidential
Restricted Restricted
Unclassified Unclassified

Called the *-property; why is it needed?

The *-rule prevents insecure
information flow
A person with a high security clearance
can read data with a high security
classification
They may (intentionally or accidentally)
write that secret information into an
object at a lower classification, violating
secrecy.
◦ What is learned from secret data may even
subconsciously influence what is written

This is permitted in a discretionary access

control system, but BLP is mandatory
access control.
◦ Prevents “giving away” data to
unauthorized persons
Problems with Bell-LaPadula
Users with higher clearances can never disseminate data to users with lower clearances.
Practical MAC systems need a means of declassification: lowering the security classification of an
object so it can be disseminated.
Observations
In discretionary access control, owners decide the security level of the data they own.
In mandatory access control, data has intrinsic security properties that must not be violated,
independently of any owner.

Confidentiality is not the only security property for data that we can consider; remember the
CIA triad.
We can also use a MAC scheme for ensuring data integrity. We won’t cover this now, though.

50
Tightening up Linux
The SELinux (Security Enhanced Linux) project allows for increasing the default
security and implementing more sophisticated access control policies on Linux
installations.
It provides elements of Mandatory Access Control and RBAC.
https://selinuxproject.org/page/Main_Page

51
Comparing the policy types
(now we get it!)
Discretionary Access Control (DAC)
◦ Rules expressed in terms of subjects, objects, and access rights
◦ Subjects can grant access rights to other subjects
◦ Implemented with:
◦ ACLs (most prevalent)
◦ Unix file permissions (primitive version)
◦ Capability lists (still experimental)

Mandatory Access Control (MAC)

◦ Subjects cannot grant other subjects additional access to any resources (objects)
◦ Key terms: security clearances and labels (classifications)

52
Comparing the policy types
(now we get it!) - 2
Role-based Access Control (RBAC)
◦ Can be discretionary or mandatory, but introduces roles in order to:
◦ Encapsulate sets of rights that are for related tasks, and
◦ Mediate the relationship between subjects and objects
◦ Helps reduce the complexity of managing many subject-object relationships, leading to fewer security
errors due to mismatches
◦ Roles and the permissions they include must be well-designed to map closely to real-world roles

Attribute-based Access Control (ABAC)

◦ Key term: logic-based
◦ Describing subjects and objects using attributes allows expressively formulating policy as a set of “if-
then” logical rules
◦ Should allow the most precise mapping between organizational policy and system policy
◦ Potentially inefficient

53
Hardware-based access
controls

54
Everything is access control?
Hardware and OS abstractions implement a type of access control.
In multi-tasking OSes, they prevent processes from interfering with each other.
Most security professionals don’t spend much time thinking about these—because they work!
The mechanisms for OS process isolation were well designed.

55
Protected CPU Instructions
Modern CPUs have protection rings; OS processes running
in less-privileged rings cannot execute instructions that
modify the system operation at a low level.
x86 architecture had four rings; only Ring 0 and Ring 3 were
ever used.

"Priv rings" by Hertzsprung at English Wikipedia. Licensed under CC BY-

SA 3.0 via Commons -
https://commons.wikimedia.org/wiki/File:Priv_rings.svg#/media/File:Pri
v_rings.svg

56
Memory Protection
OS memory protection is a type of access control.
In a multi-tasking operating system, processes must be able to access only
their own memory region; they should not be able to read or write the
memory being used by other processes.
Memory protection is implemented by the mechanism of Virtual Memory.
◦ Makes each process appear to have the entire memory space to itself.
◦ Other processes’ memory pages don’t even seem to exist.
◦ Supported at the hardware and OS level.

What they didn’t think of was protection within the memory of a single
process!
◦ Arbitrary executable code can be injected into process memory through buffer
overflows and executed
◦ Turned out to be one of the major sources of security breaches

57
Virtualization Security
Now it is common for multiple operating systems to be run simultaneously on the same
hardware.
Virtual Machine Monitor (VMM) software includes protection mechanisms to prevent virtual
machines running on the same host machine from spying on each other or interfering with each
others’ activity.
◦ Makes use of CPU protection rings. Ring 0 instructions executed by a VM are intercepted by the monitor
and applied to the virtual (not real) hardware.

However, several successful proof-of-concept attacks have been demonstrated in which a

malicious VM can recover data from co-located VMs.
◦ Basic idea: measure how much a co-located systems activity slows down certain processes.

58
Assignments
1. Read through Chapter 4, of the textbook
2. Homework 2, posted on Blackboard
3. Lab Exercise: ACLs in Windows
Research Paper reading and hands-on lab activities will be assigned on alternating weeks.

59