CONTROL FLOW

Overview

q Access control: What and Why

q Abstract Models of Access Control

q The Unix Access Control Model

q Capabilities

q Beyond the Unix Model

q Multilevel Security

2
Digitally signed by
Dr. Nirmalya Dr. Nirmalya Kar
Kar Date: 2024.04.01
10:30:14 +05'30'
 What goes into system security?
q Authentication (password/crypto/etc.)
qWho are you?

q Authorization (Acess control)

qWhat are you allowed to do.
qFocus is policy

q Enforcement Mechanism
q How its policy implemented/enforced

Today we are mostly interested in #2, will touch on #3

Note: split between policy and mechanism sometimes a false dichotomy.

Access Control
q “The prevention of unauthorized use of a resource, including the
prevention of use of a resource in an unauthorized manner“

q Central element of computer security

q Assume have users and groups

• authenticate to system
• assigned access rights to certain resources on system

4
 Night Club Example
• Authentication
• ID Check
• Access Control
• Over 18 - allowed in
• Over 21 - allowed to drink
• On VIP List - allowed to access VIP area
• Enforcement Mechanism
• Walls, Doors, Locks, Bouncers

Night Club Example: More Interesting Phenomena

• Tickets
• Name or anonymous?
• Date

• What if you want to leave and come back

• Hand stamp or bracelet

6
 Why this Tangent?
q We can find logical models to study these systems?
q We can use these models to design new systems?

• Security systems are everywhere, looking at the real world key to building
your intuition.

What do we use this for?

q Express information access policies.
q Who can access my files, who can’t, how.
q Sandboxing: Minimize damage inflicted by malicious program.
q Privilege Seperation: Allow programs to be written to minimize
damage in case of failure.
q Think about compartments in a ship

Defense-in-Depth
- programmers make mistakes, protection systems fail, redundancy
always a good thing!!

8
 Basic Design Space
q All security architectures are Isolation + Controlled Sharing
q Just Isolation
ü Unplug the network cable! (airgap provides almost perfect isolation).
ü Segment your network physically
• Put red tape on one set of wires and machines, black tape on another, blue on another.
• Make sure colors always match!
ü Military exploits this approach to separate classified, secret, topsecret
networks.
qMost of us need to share stuff…what do we want from sharing?

Challenge of Controlled Sharing

q All of Saltzer and Schroder’s principles are vital,

However, these two are hard.

v Principle of Least privilege
• Make controls granular enough and apply them to enforce them to minimize
harm.
v Psychological acceptability
• Get as close to the users mental model (be it the programmer, user or admin) as
possible.

Reconciling these two is a fundamental challenge.

10
 Challenge of Controlled Sharing
q All of Saltzer and Schroder’s principles are vital,

However, these two are hard.

v Principle of Least privilege
• Make controls granular enough and apply them to enforce them to minimize harm.
v Psychological acceptability
• Get as close to the users mental model (be it the programmer, user or admin) as
possible.

Reconciling these two is a fundamental challenge in Access Control.

11

Operating Systems: Our focus today

• Most heavily studied area for access control
• First computers where single user/no network
• Timesharing systems introduced need for access control
• studied heavily in the 70’s and 80’s.
• Still an open research area, why?
• First 20 years: restrict what a user can do with data, focus on military problems, thought
problem was malicous users
• Last 10: Malicous applications the primary problem.

• Another answer: Right Access control policy dictated by Usage models, Threat Model,
Applications -- we still have lots to learn about how programs are built, how people use them.

12
 Access Control vs. IDS and AV
q Soundness (can I make a definite allow/deny decision)
• Difference between access control and intrusion detection
• An IDS makes a probablistic statement i.e. this action is probably bad - allows catching a
broader range of behaviors, at the cost of enforcement.
• An IDS that is 100% accurate should be doing enforcement, it is then an IPS (access control
system)
q Completeness (do I catch every bad action)
• Access control vs. AV
• Access control systems should (in theory enforce some property) -- e.g enforce these rules on
information flow.
• AV systems often rely more on un-sound blacklist approach, hard to make strict statements
about what your getting
q In the real world, distinctions often unclear
• Your AV product may do some access control

13

Access Control Principles

14
15

Abstract Models of Access Control

17
 Access Control Elements
q Subjects : entity that can access objects
• can be processes, modules, roles

q Objects : access controlled resource

• can be files, processes, etc.

q Access right: way in which subject accesses an object

• e.g. read, write, execute, delete, create, search

q Authentication often used to bootstrap subjects, but not necessary.

• e.g. process assumes identity of one subject, then another.

18

Elementary Forms
q Authentication = Authorization
v e.g. safes
q Whitelists/Blacklists (Single object, multiple Subjects)
v Examples: Spam prevention
v Blacklists:
• Default on (fail open)
• Hard to reason about who can access system
v Whitelists:
• Default off (fail closed)
• Have to deal with adding whitelist entries
q Challenges
• Hard to manage if rapidly changing set of principles
• Both can grow quite large

19
20

21
22

Discretionary Access Control

q Often provided using an access matrix
ü lists subjects in one dimension (rows)
ü lists objects in the other dimension (columns)
ü each entry specifies access rights of the specified subject to that object

q Access matrix is often sparse

q Can decompose by either row or column

23
 Access Control Matrix
• Instantaneous protection state of a system
• Dynamically Changing!
• How can we extend this model?
Objects

A B C D
alice
0 0 1 0
bob
subjects 1 1 0 1
charlie
0 0 1 0
dave 1 1 0 1

24

Adding Access Rights

q Access Rights
• e.g. Simple: Read, Write
• e.g. Complex: execute, change ownership
Objects

A B C D
alice
r r/w r -
bob
subjects r r - r/w
charlie
- - w -
dave r/w - w

25
 Grouping

q Subjects
• Groups e.g. staff = {alice,dave}, students = {bob, charlie}
q Objects
• Types e.g. system_file = {A,B}, user_file = {C,D}
q Can have compound names
• e.g. in AFS talg:friends, system:backup

26

ACL’s
q What if I break my matrix down by columns?
• Each object has a set of <user, right> tuples
• A {<bob, r/w>, <alice,w>}
q Properties
• Good for many applications (file systems)
• Can grow quite large

27
 Capabilities
qWhat if I break my matrix down by rows
ü Alice {<A,r/w>, <B,w>, <C,r>}

qProperties
ü Natural model for delegation (rights coupled to object)

qEach tuple can be viewed as a handle to an object

28

Protection Domains
q Users don’t exist
• Machines, processes, modules,do
q Protection domain is an abstract object that can have
ü A namespace (e.g. view of the file system)
ü A userid or group ID
ü A set of objects it holds (capability list)
ü A set of rights it holds (permissions)
q How does protection get enforced?
• Language type systems, hardware MMU (Processes, virtual machines),
compilers (SFI)

v Not our primary interest today

29
 The Reference Monitor
q An abstract model of protection
q Sometimes quite close to implementation
q e.g. SELinux (Flask Architecture)

q In practice should offer:

q Complete mediation
q Be Tamper proof
q Be small enough to understand (verify)

• Important Idea: Computer systems are BIG and Complex, Security relavent part often SMALL,
extract that part out that deals with security so that we can understand/verify it.

30

Access
Control
Function

31
 Access control system commands

32

Protection Domains: More Useful

ü Set of objects together with access rights to those objects
ü More flexibility when associating capabilities with protection domains
ü In terms of the access matrix, a row defines a protection domain
ü User can spawn processes with a subset of the access rights of the user
ü Association between a process and a domain can be static or dynamic
ü In user mode certain areas of memory are protected from use and
certain instructions may not be executed
ü In kernel mode privileged instructions may be executed and protected
areas of memory may be accessed

33
 Unix Access Control

Basics, limitations, extensions

34

Unix Resource
• Files
• Includes devices, IPC (domain sockets, named pipes, mmap shared memory)
• Network
• TCP/UDP port address space
• Other
• Sys V IPC has its own name space
• ability to load kernel modules

35
 Unix Identities
q Each process has set of identities used to make access control decisions.
• Conceptually uid/euid, gid/egid most important

q euid used for access control decisions

• Allows process to drop and resume privilege temporarily

q Changing uid/euid allows dropping privilege permanently.

36

UNIX File Concepts

q UNIX files administered using inodes (index nodes)

q An inode:
ü control structure with key info on file (attributes, permissions, …)
ü on a disk: an inode table for all files
ü when a file is opened, its inode is brought to RAM

q Directories form a hierarchical tree

ü may contain files or other directories
ü are a file of names and inode numbers

37
 File system access control

user group other

• “-rwxrwxrwx

q Unique user identification number (user ID)

q Member of a primary group identified by a group ID
q 12 protection bits
ü 9 specify read, write, and execute permission for the owner of the file, members of the group and all other users
ü 2 speficiy SetID, SetGID
ü 1 is the sticky bit (only owner can remove, delete, …, a directory)

q The owner ID, group ID, and protection bits are part of the file’s inode

38

File system access control

• “set user ID”(SetUID) or “set group ID”(SetGID)
• system temporarily uses rights of the file owner/group in addition to the real user’s rights when
making access control decisions
• enables privileged programs to access files/resources not generally accessible
• Sticky bit
• on directory limits rename/move/delete to owner
• Superuser
• is exempt from usual access control restrictions

39
 UNIX Access Control Lists
• Modern UNIX systems support ACLs
• Can specify any number of additional users/groups and associated rwx
permissions
• When access is required
• select most appropriate ACL
• owner, named users, owning/named groups, others
• check if have sufficient permissions for access

40

41
42

43
44

45
 What can you do with identities
q Lots of hard coded rules
q Highest privilege uid is root (uid = 0), has most privilege,
ü Access privileged ports, override file permissions, load kernel modules, etc.
ü Once you have root, you own the system
ü this is a source of many problems.
q Process with a given euid can send signals to other processes with that uid, ptrace()
those processes, etc.
ü Basically no protection between processes with same uid.
q Good news
ü Works decently well on multi-user system where programs are not malicous --
shortcomings can be fixed with file system ACL’s
q Bad News
ü Very difficult/sometimes impossible to contain damage of malicous root process
ü Lots of stuff needs root
ü Users can’t protect themselves from bad apps, i.e. apps totally trusted!!

46

Dropping privilege
• Only available to root
• To prevent programmer errors
• Assume role of less privileged user for most operations (set euid)
• Let OS do its job
• Only keep privilege long enough to do what you need.
• Temporary, program can resume root privilege at will
• Essential for some things in unix (e.g. race free file open)
• NEVER try to impersonate another user as root!
• You will fail

• To prevent malicious code from inflicting damage

• Drop privilege permanantly (often accompanied by fork()).
• Works well if there is a before-time (with privilege)/after-time(without privilege) model. e.g.
daemons that need root to listen to privileged port.

47
 Separating Time of Check and Time of Use - A Really Bad Thing

• Example: access() system call.

int access(const char *path, int mode);
#From the man page:
#Access() is a potential security hole and should never be used.

• Problem: as soon as you get a result from access(), its invalid. Permissions could have
changed.
• Checking Permission/obtaining resource must be atomic!
• Solution: Never use access(), instead look up programming guidelines for your OS.

Hint: Never make up your own solution!

48

Confused Deputy Problem

q Pay-to-play compiler service (its an old problem)
ü Compiler service takes file and compiles it for user
ü User hands compiler path for compilers own billing file
ü Compiler overwrites billing file

Compiler was a confused deputy - acting on behalf of user.

Solutions:
Ø Drop privilege to that of user to open file (more error prone, common source of
bugs)
Ø Have user pass capability to compiler (less error prone).
Ø Capability advocates love to point this out as reason to use capabilities.

50
 File descriptor passing: the poor mans capability system
q File descriptors are capabilities
q Ability to delegate files by passing descriptors over a unix domain socket
(sendmsg(), recvmsg())
q Supports privilege seperation
• One process runs as root, opens a unix domain socketpair.
• Forks() another process, drops privilege
• More privilege process can pass descriptors to less privilege process, also do other stuff e.g.
manage crypto keys.
• Can apply this paradigm ad naseum i.e. multiple unprivileged processes.
q Trade-offs
Ø Positive: Great way to make more robust software
Ø Negative: sometimes very hard to do after the fact (don’t believe the hype), requires pretty clueful
programmers up front.

51

Capabilities have lots of nice properties

• Natural model for delegation
• Just pass handle to object
• No ambient privilege
• Access control explicit not implicit
• Separate access checking from use
• E.g. fd = open() vs. read(fd), write(fd)
• Useful design pattern for ammoritizing the cost of permission checks

• Powerful extensibility in languages that support capabilities natively

• Wrap one object in another object.

52
 Still More…
• Cryptographic Capabilities
• Nonce as index into table (stateful)
• {<permissions>, objectid, MAC(msg)} (stateless)
• No OS support need, good for distributed systems
• Limitations of capabilities
• No easy means of revocation
• Can’t easily control delegation in a pure model (mostly a red herring)
• Doesn’t always suit your problem

53

Some Real World Access Control

Mechanisms
Or, overcoming the shortcomings of
the original Unix model.

54
 Dangers of bad access control model
• Too much privilege!
• Original Unix architecture suffers severly
• Windows world even worse
• Once ISV’s (developers) expect this, very hard to go back!
• Wrong granularity
• To coarse grain => too much privilege
• To fine grain => too many knobs, no one knows how to use it
• (SELinux struggles with this, its gotten better, but still not for the faint of heart)
• Compromise
• Protection Profiles, Roles, etc. - use fine grain permissions to build up common case profiles.

55

File system ACL’s

• Basic Problem
• I want to do a project with a new group, how do I share files with only them without involving my
sysadmin?
• Ghetto style
• Create a directory accessible but not readable by everyone
• Make directory (or files) in that directory with secret name
• Hand out name as a capability
• Gross and many limitations…
• ACL’s a better soluation
• User created groups, user setable list of groups/users on files/directories
• Almost everywhere now
• AFS, NTFS, NFSv4, FreeBSD, Solaris, ZFS, etc.

56
 Chroot()
• Basic idea: Allow process to
change file system root: e.g.
chroot(“/home/apache/base”);

/
• Variety of sharp edges due to
power of root user, ptrace(),
etc. home
etc bin
• BSD Jail tries to fix this. apache
• Fundamental problem, limited
controlled sharing. base
• Still, a useful primitive etc bin
• Richer primitive in plan9, a
research OS.

57

Posix “Capabilities”
• Paritioning power of root
• CAP_DAC_OVERRIDE: ignore normal file permissions
• CAP_CHOWN: allow arbitrary chown
• CAP_SYS_NET_BIND_SERVICE: allow bind of TCP/UPD sockets below port 1024
• CAP_NET_RAW: allow raw socket access (can create arbitrary ethernet frames)

• Improvement on setuid
• Doesn’t help with files
• Fixed granularity

58
 Sandboxing Systems
• Examples: AppArmor (SuSe), Systrace, Janus

59

SELinux
• Adding MAC to Linux
• Flexible policy architecture
• DTE, RBAC, MLS
• Default uses combination of RBAC and DTE
• Checks applied if existing unix model succeeds e.g. if access fails,
additional checks not invoked
• Most folks never use MLS

60
 Domain and Type Enforcement
• Generalization of Access Control Matrix
• Processes have a domain
• Objects (generally files) have a type.
• Stored in extended file attribute
• Type set at system configuration time.
Example:
assign -u /home user_t
assign -u /var spool_t

• Entry point to domain is generally a binary e.g. (exec /usr/bin/lpd => domain lpd_t)
• App can request a domain transition to drop privilege
• Nice compared to path base model in that more robust to file rename(), can be less prone to problems
due to symlinks, etc.

61

62
 RBAC
q Yet another generalization of our access control matrix
q Add yet another label to processes
q Instead of uid, access control decisions based on role
q e.g. Bob acting as backup manager vs. bob acting as printing manager.

63

q Access based on
‘role’, not identity

q Many-to-many
relationship
between users and
roles

q Roles often static

64
65

66
67

68
69

Role-Based
Access Control

Double arrow: ‘many’ relationship

Single arrow: ‘one’ relationship

71
 Example of role hierarchy
• Director has most privileges
• Each role inherits all privileges from lower roles
• A role can inherit from multiple roles
• Additional privileges can be assigned to a role

72

Constraints
A condition (restriction) on a role or between roles
q Mutually exclusive
• role sets such that a user can be assigned to only one of the role in the set
• Any permission can be granted to only one role in the set

q Cardinality: set a maximum number (of users) wrt a role (e.g., a department chair
role)

q Prerequisite role: a user can be assigned a role only if that user already has been
assigned to some other role

73
 Attribute-based access control
• Fairly recent
• Define authorizations that express
conditions on properties of both the
resource and the subject
• Each resource has an attribute (e.g., the
subject that created it)
• A single rule states ownership privileges for the
creators
• Strength: its flexibility and expressive
power
• Considerable interest in applying the model
to cloud services

74

75
76

77
78

ACL vs ABAC trust relationships

79
 ACL vs ABAC trust relationships

80

Identity, Credential, and Access Management

(ICAM)
q A comprehensive approach to managing and implementing digital
identities, credentials, and access control
q Developed by the U.S. government
q Designed to create trusted digital identity representations of
individuals and nonperson entities (NPEs)
q A credential is an object or data structure that authoritatively binds
an identity to a token possessed and controlled by a subscriber
q Use the credentials to provide authorized access to an agency’s
resources

81
 1. Connects digital identity
to individuals

ICAM
2. Data structures that binds
a token possessed
by a subscriber

4. Identity verification of
individuals from external
organizations 3. Management of how access
is granted to entities

82

Bell-LaPadula Model: A MAC Model for Achieving Multi-level Security

• Introduce in 1973

• Air Force was concerned with security in time-

sharing systems
• Many OS bugs
• Accidental misuse

• Main Objective:
• Enable one to formally show that a computer system can
securely process classified information

83
 Multi-Level Security (MLS)
• There are security classifications or security levels
• Users/principals/subjects have security clearances
• Objects have security classifications
• Example of security levels
• Top Secret
• Secret
• Confidential
• Unclassified
• In this case Top Secret > Secret > Confidential > Unclassified
• Security goal (confidentiality): ensures that information do not
flow to those not cleared for that level

84

85
86