Introduction to Computer

Security Lecture Slides

© 2022 by Mihai Chiroiu
is licensed under Attribution-NonCommercial-ShareAlike 4.0
International
Authorization.
Access Control
Associate Prof. Florin Stancu
Examples of Access Control
• Social Networks: access to personal information.
• Web Browsers: access only to a website (same origin policy).
• Operating Systems: one user cannot arbitrarily access/kill another
user’s files/processes.
• CPU Memory Protection: code in one region (e.g., Ring 3), cannot
access the data in another more privileged region (e.g. Ring 0).
• Firewalls: If a packet matches with certain conditions, it will be
dropped.

© Mihai Chiroiu 3
Access control
(1) Identify

(2) Authenticate

(3) Authorize

(4) Audit

4
PEI Model [1]
Security and system goals Necessarily Informal

What Policy models Formal/quasi-formal

Enforcement models System block diagrams, Protocol flows

How

Implementation models Pseudo-code

Trusted Computing Technology Actual code

© Mihai Chiroiu 5
Vocabulary
• Basic abstractions:
• Subjects
• Objects
• Rights
• A subject is an entity who wishes to access a certain object, which is
a resource (e.g., a file or a network packet). The different modes of
access (e.g., reading, writing) are called permissions.

© Mihai Chiroiu 6
Vocabulary – Users and Principals

Real World User

Principals - Unit of Access
Control and Authorization

A Principal is an User authenticated in a context

© Mihai Chiroiu 7
Vocabulary – Users and Principals
Principals
Mihai.top-secret (TS)

User Mihai.secret (S)

Mihai Mihai.Confidential (C)

Mihai.Unclassified (U)

Example: the user can emit principals with downgraded privileges

© Mihai Chiroiu 8
Vocabulary – Principals and subjects

Chrome

PowerPoint

Principal Thunderbird
Mihai.TS Winamp
Subjects
A subject is a program executing on behalf of a principal

© Mihai Chiroiu 9
Vocabulary
• The relation between Users and Principals is One-To-Many
• Allows accountability of user’s actions, use least privileges required for a
task
• E.g., service accounts / API keys (authentication w/o password)
• For simplicity, a principal and subject can be treated as identical
concepts.

© Mihai Chiroiu 10
Vocabulary - Objects
• An object is anything on which a subject can perform
operations (mediated by rights)
• Usually objects are passive, for example:
• File
• Directory (or Folder)
• Memory segment
• But, subjects (e.g., processes) can also be objects, with
specific operations
• kill
• suspend
• resume

© Mihai Chiroiu 11
Access control models

© Mihai Chiroiu 12
Access control enforcement
• Discretionary access controls (DAC) – the access of objects (or
subjects) can be propagated from one subject to another.
Possession of an access right by a subject is sufficient to allow
access to the object.
• Mandatory access controls (MAC) – the access of subjects to
objects is based on a system-wide policies (based on security labels)
that can be changed only by the administrator.
• Role-Based Access Control (RBAC) – can be configured as both MAC
or DAC, access to objects is based on roles.

© Mihai Chiroiu 13
Access control enforcement
• Attribute-Based Access Control (ABAC) – properties of an object are
used when usage decision are made.
• Usage Control (UCON) – generalization of access control to include
authorization, obligations, conditions (e.g., quotas), continuity and
mutability of attributes.

© Mihai Chiroiu 14
Discretionary access controls

© Mihai Chiroiu 15
DAC
• No precise definition.
• Basically, DAC allows access rights to be propagated at subject’s
discretion
• often has the notion of owner of an object
• used in UNIX, Windows, etc.

© Mihai Chiroiu 16
Formal rule representation
• Let S be the set of all subjects, O the set of all objects, and P the set
of all permissions. The description of access control can be given by
a set A ⊆ S × O × P.
• When new permissions are added, triplets are added to A; when
they are removed (revoked), triplets are deleted.

© Mihai Chiroiu 17
Matrix Representation
• An access control matrix is a matrix (Ms,o) whose rows are subjects
and columns are objects. Element (Ms,o) ⊆ P is the set of
permissions that subject S is authorized for object o.
Objects (and Subjects)
catalog.csv cat-anonim.txt /dev/kmem /sbin/sudo PID 1001

Subjects Root rw rwx - rwx kill

mihai rw rw - rx kill
student - r - rx -
guest - - - - -

© Mihai Chiroiu 18
Access Control Lists (ACL)
• An access control list is a set {Ao | o ∈ O}, one element for each
object. The elements of the list are the pairs (s, p) of subjects s who
have permission p to that object.

catalog.csv cat-anonim.txt /sbin/sudo

root: rw root: rw root: rwx
mihai: rw mihai: rw mihai: rx
student: r student: rx

© Mihai Chiroiu 19
Classic POSIX Model
● Objects: files; Permissions: R, W, X + specials (SUID/SGID/sticky)
● Subjects: users, groups, others
● Stored as bit masks (written in base 8 – octal) on inodes
➜ ls -l /usr/bin/ping
-rwxr-xr-- 1 root admin 92K Jan 18 08:05 /usr/bin/ping

Bit mask: 111|101|100 => octal 754

● Modern OSes support Full Access Control Lists

○ multiple subjects!

20
Capability Lists
• Alternate access control implementation: each user stores a list of
his/hers capabilities instead of objects’ storing ACLs.
• Storing capabilities means giving to each subject tokens which give them
access to the permissions they are entitled
catalog.csv cat-anonim.txt /dev/kmem /sbin/sudo PID 1001
Root rw rw rw rwx kill
mihai rw rw - rx kill
student - r - rx -
guest - - - - -

© Mihai Chiroiu 21
Capability examples
• Posix API [pseudo]example:
int fd = open("/etc/passwd", O_RDWR);
Code flow: fork() -> setuidgid() -> exec()
-> new process inherits fd (the authorization “token”)

• Windows/Active Directory: Security Identifier (SID) to give access on

remote Systems

© Mihai Chiroiu 22
ACL vs. Capabilities
• ACL require authentication of subjects
• Capabilities do not require authentication of subjects, but do
require unforgeability and control of propagation of capabilities.
Usually implemented through cryptography.
• The Confused Deputy Problem [1986]
• E.g.: Cross-Site Scripting / Forgery (XSS / CSRF), setuid privilege escalation
(e.g., sudo)
• Solution: bundle resource access together with capability

© Mihai Chiroiu 23
DAC Problems
• The underlying philosophy of DAC is that subjects can determine
who has access to their objects
• There is a difference, though, between trusting a person and trusting a
program
• The copies of a file are not controlled
• Trojan Horse attack [1970]
• Solution: use MAC ☺

© Mihai Chiroiu 24
Trojan Horse attack
ACL
Principal A A:r
File F A:w
read
Good Program

Trojan
Horse B:r
write File G A:w

Principal B cannot read file F

© Mihai Chiroiu 25
Buggy software can become Trojan Horses
• When a subject (e.g., buggy software) is exploited, it executes the
code / intention of the attacker, while using the privileges of the
user who started it!
• This means that DAC-only systems cannot be trusted with classified
information!

© Mihai Chiroiu 26
Principle of Least Privilege
• Each subject should have only necessary privileges!
• Privilege elevation / dropping
• Unix: setuid() / setgid() family of system calls
• Example POSIX scenario:
• Only root can open ports <= 1024
• Web server (e.g., apache2) starts as root
• Opens log files, sockets etc. when root then drops all root privileges (user
changes to www-data)!
• Modern alternative: Linux capabilities (CAP_NET_BIND_SERVICE)
• Better yet: DAC + Mandatory Access Control!

© Mihai Chiroiu 27
Mandatory access controls

© Mihai Chiroiu 28
Mandatory Access Control
• Assigning access rights based on regulations by a central authority
• Implemented using a “reference monitor”
• Small Trusted Computing Base (TCB) [John Rushby, 1981, OSP]
• Kernel < Hypervisor < Hardware
• TOCTTOU (Time Of Check To Time of Use) problem:
• authority checks access to an object
• unknowingly to him, attacker replaces object with another one
• privileged subject operates on attacker controlled object!

© Mihai Chiroiu 29
MAC implementations
• Type Enforcement (e.g.: SELinux)
• Subjects => grouped in domains (labels)
• Objects => grouped in types (another / same kind of labels)
• Domain-Domain + Domain-Type permissions
• If a MAC rule fails => DAC not checked, access denied!
# TE rule: allow passwd_t shadow_t : file {read, write …}
# ls -Z /etc/shadow
-r---- root root system_u:object_r:shadow_t shadow
# ps -aZ
gigel:user_r:passwd_t 16532 pts/0 00:00:00 passwd

30
Modeling Access Control
• Multi-level security (MLS)
• Bell-LaPadula (BLP)
• Biba Model
• Chinese Wall

© Mihai Chiroiu 31
Multi-level security (MLS)
• The capability of a computer system to carry information with
different sensitivities Top Secret

• Bell-LaPadula (BLP) Model [1973] Secret

• Biba Model dominance can flow

Confidential

Unclassified
© Mihai Chiroiu 32
BLP Model
• Aims to capture confidentiality (read) requirements only
• Modelled as transitions through a set of states, starting from an
initial state.
• State = Object, access matrix, current access information
• State transition rules describe how a system can go from one state
to another
• Each object has a classification level
• Each subject s has a security clearance

© Mihai Chiroiu 33
BLP Model
• A state is secure if:
• A) Simple Security Property (SS): no subject may read data at a higher level
• B) The *(Star)-Property (SP): no subject may write data at a lower level
(due to the fear of Trojan Horse / information leaks)

• A system is secure if and only if every reachable state is secure.

© Mihai Chiroiu 34
BLP Problems
• No communication (e.g., acknowledges) from High to Low
• Not all system components can be enforced by BLP, e.g., memory
management must have access to all levels
• Called “trusted subjects” (part of TCB)
• Can overwrite high and more important files
• Prevent overwrites unless same level!

© Mihai Chiroiu 35
BLP Problems
• Covert channels cannot be blocked by star-property

High Trojan Horse

Top Infected Subject
Secret
Timing / size of packets being
sent

Low Trojan Horse

Unclassified Infected Subject

© Mihai Chiroiu 36
Biba Model
• Integrity is also very important
• Each subject (process) has an integrity level; Each object has an
integrity level ; Integrity levels are totally ordered
• NO read down; NO write up
• BLP upside down
• The integrity of an object is the lowest level of all the objects that
contributed to its creation

© Mihai Chiroiu 37
Biba Model
• Used by Windows
• E.g., A Internet Explorer Browser can download a file (created with a
low integrity level) and read everything in the system. It cannot
write to a higher level object.

© Mihai Chiroiu 38
Chinese Wall (Brewer and Nash model)
[1989]
Conflict of Interest Classes (CIC) Conflict of Interest Classes

Company Company
Datasets (CD1) Datasets (CD3)

O1 O2 O5 O7
O8
O4 O6 O9
O3
Company Company
Datasets (CD2) Datasets (CD4)

© Mihai Chiroiu 39
Chinese Wall
• S can read O only if
• O is in the same company dataset as some object previously read by S (i.e.,
O is within the wall) or
• O belongs to a conflict of interest class within which S has not read any
object (i.e., O is in the open)
• S can write O only if
• S can read O by the simple security rule and
• no object can be read which is in a different company dataset to the one for
which write access is request

© Mihai Chiroiu 40
Role-Based Access Control

© Mihai Chiroiu 41
Role-Based Access Control
• In the real world, security policies are dynamic.
• E.g., a user promotes at his job, therefore his rights must change
(deleted, added, etc.)
• RBACs are more flexible: can simulate MAC & DAC!
Discretionary Access Control Mandatory Access Control
(DAC), 1970 (MAC), 1970

Role Based Access Control

(RBAC), 1995

© Mihai Chiroiu 42
Roles as policy
• A role brings together
• a collection of users
• a collection of permissions
• These collections can be modified independently
• A user can be a member of many roles
• Each role can have many users as Each role can have many users as
members
• Roles may be hierarchical

© Mihai Chiroiu 43
Role-Based Access Control
Permissions
(e.g., read,
Users Roles write,
append,
execute)

Sessions
… (Principals)

© Mihai Chiroiu 44
RBAC Shortcomings
• Role granularity may lead to role explosion
• Role design and engineering is difficult and expensive
• Assignment of users/permissions to roles is cumbersome
• Adjustment based on local/global situational factors is difficult

© Mihai Chiroiu 45
Authorization Implementations

© Mihai Chiroiu 46
OAuth
• Open Authorization, not Authentication!
• Users delegate API access to third party services without giving
password!
• e.g. give Google Calendar API access to task management app
• JSON Web Token (JWT) – may contain subject IDs + capability lists
• Authorization flow: client / server-side
• OpenID Connect: OAuth popular choice for SSO authentication!
• Obtain token with read-only access to Google API endpoint returning your
email address => third-party service identifies you!

© Mihai Chiroiu 47
Writing Authorization Code
● Tons of conditionals?
if is_admin or (can_read(obj.parent) and can_write(obj)) ...

● Solution: use language features & authorization frameworks

@authorize.create(Article)
def create_article(name):
# implementation here

@authorize.read
def read_article(article):
# implementation here

48
Best Practices
• Design during early requirements phase
• Model as subjects, objects and permissions
• Use an appropriate policy model (DAC, RBAC, ABAC etc.)
• Use middleware / framework if available
• If not, create your own! DO NOT copy-paste duplicate code!
• Implement resource limits / quotas
• Sanitize/normalize user input !!!
requested_file.startswith("/home/user/share/")
requested_file = "/home/user/share/../../../etc/shadow"

49
The Human Factor

© Mihai Chiroiu 50
Security and humans
• Security policies must be in place
…and must be followed.

• Regardless of how strong (and expensive) your secure deployment is:

• Humans can still write their passwords on post-it notes
• Humans can still give their passwords to anyone they trust
• Humans can still open tempting attachments…

© Mihai Chiroiu 51
Social engineering
• Non-technical intrusion
• Involves tricking people to break security policies
• Manipulation
• Relies on false confidence
• Everyone trusts someone
• Authority is usually trusted by default
• Non-technical people don’t want to admit their lack of expertise
• They ask fewer questions.
• Most people are eager to help.
• When the attacker poses as a fellow employee in need.

© Mihai Chiroiu 52
Social engineering
• People are not aware of the value of the
information they possess.
• Vanity, authority, eavesdropping – they all
work.
• When successful, social engineering
bypasses ANY kind of security.

© Mihai Chiroiu 53
Types of phishing
• By used technology
• Smishing (SMS)
• Vishing (Voice)
• Email phishing
• Angler phishing (via social networks)
• By target
• Watering Hole Phishing (people visiting a certain website)
• Spear phishing (a specific organization)
• Whaling (C-level from a specific organization)

54
Resources
[1] http://www.profsandhu.com/confrnc/asiaccs/asiaccs06-pei.pdf
[2] http://www.cs.cornell.edu/courses/cs5430/2011sp/NL.accessControl.html
[3] http://cnitarot.github.io/courses/cs526_Spring_2015/s2014_526_ac.pdf
[4] https://people.cs.rutgers.edu/~pxk/419/notes/access.html

© Mihai Chiroiu 55