Access Control
Jeff Chase
Duke University
The need for access control
• Processes run programs on behalf of users. (“subjects”)
• Processes create/read/write/delete files. (“objects”)
• The OS kernel mediates these accesses.
• How should the kernel determine which subjects can
access which objects?
This problem is called access control
or authorization (“authz”). It also
encompasses the question of who is
authorized to make a given statement.
The concepts are general, but we can
consider Unix as an initial example.
Identity in an OS (Unix)
• Every process has a security label that
governs access rights granted to it by kernel.
• Abstractly: the label is a list of named
attributes and values. An OS defines a
space of attributes and their interpretation.
• Some attributes and values represent an
identity bound to the process.
• Unix: e.g., userID: uid
uid=“alice”
Every Unix user account
has an associated userID
(uid). (an integer)
credentials
uid
There is a special administrator uid==0 called root or superuser or su.
Root “can do anything”: normal access checks do not apply to root.
Labels and access control
Every system defines rules for
assigning security labels to
subjects (e.g., Bob’s process)
and objects (e.g., file foo).
Alice
login
shell
Every system defines rules to
compare the security labels to
authorize attempted accesses.
Bob
login
shell
creat(“foo”)
tool
uid=“alice”
write,close
foo
open(“foo”)
read
owner=“alice”
Should processes running with
Bob’s userID be permitted to
open file foo?
tool
uid=“bob”
Unix: setuid and login
Alice
• A process with uid==root may change its
userID with the setuid system call.
log in
• This means that a root process can speak
for any user or act as any user, if it tries.
(runs as root)
login
setuid(“alice”),
(runs as alice)
exec
shell
• This mechanism enables a system login
process to set up a shell environment for a
user after the user logs in (authenticates).
This is a refinement of privilege.
fork/exec
tool
uid=“alice”
A privileged login program verifies a user
password and execs a command interpreter
(shell) and/or window manager for a logged-in
user. A user may then interact with a shell to
direct launch of other programs. They run as
children of the shell, with the user’s uid.
Labels and access control
Alice
Every file and every process is
labeled/tagged with a user ID.
log in
login
setuid(“alice”),
A privileged process may
set its user ID.
exec
Bob
log in
login
setuid(“bob”),
shell
exec
shell
fork/exec
fork/exec
creat(“foo”)
tool
write,close
uid=“alice”
A process inherits its userID
from its parent process.
foo
open(“foo”)
read
owner=“alice”
tool
uid=“bob”
A file inherits its owner userID from
its creating process.
Labels and access control
Every system defines rules for
assigning security labels to
subjects (e.g., Bob’s process)
and objects (e.g., file foo).
Alice
login
shell
Every system defines rules to
compare the security labels to
authorize attempted accesses.
Bob
login
shell
creat(“foo”)
tool
uid=“alice”
write,close
foo
open(“foo”)
read
owner=“alice”
Should processes running with
Bob’s userID be permitted to
open file foo?
tool
uid=“bob”
Concept: reference monitor
requested
operation
“boundary”
protected
state/objects
identity
subject
program
guard
A reference monitor is a program that controls access to a set of
objects by other programs. The reference monitor has a guard that
checks all requests against an access control policy before
permitting them to execute.
Requirements for a reference monitor
requested
operation
“boundary”
protected
state/objects
identity
subject
program
guard
1. Isolation: the reference monitor is protected from tampering.
2. Interposition: the only way to access the objects is through the
reference monitor: it can examine and/or reject each request.
3. Authentication: the reference monitor can identify the subject.
Reference monitor
requested
operation
“boundary”
protected
state/objects
identity
subject
program
guard
What is the nature of the isolation boundary?
If we’re going to post a guard, there should also be a wall.
Otherwise somebody can just walk in past the guard, right?
The kernel is a reference monitor
• No access to kernel state by user programs, except
through syscalls.
– Syscalls transfer control to code chosen by the kernel, and not
by the user program that invoked the system call.
• The kernel can inspect all arguments for each request.
• The kernel knows which process issues each request,
and it knows everything about that process.
• User programs cannot tamper with the (correct) kernel.
– The kernel determines everything about how the machine is set
up on boot, before it ever gives user code a chance to run.
• Later we will see how the kernel applies access control
checks, e.g., to file accesses.
Another way to setuid
Alice
• The mode bits on a program file may be
tagged to setuid to owner’s uid on exec*.
log in
• This is called setuid bit. Some call it the
most important innovation of Unix.
login
fork
setuid(“alice”)
exec
fork
exec(“sudo”)
setuid bit set
/usr/bin/sudo
fork
exec(“tool)
• It enables users to request protected ops
by running secure programs.
shell
sudo
tool
uid=“root”
• The user cannot choose the code: only the
program owner can choose the code to
run with the owner’s uid.
• Parent cannot subvert/control a child after
program launch: a property of Unix exec*.
Example: sudo program runs as root, checks
user authorization to act as superuser, and (if
allowed) executes requested command as root.
Unix setuid: recap
Alice
Refine the privilege
of this process (using
setuid syscall).
login
uid = “root”
setuid(“alice”)
exec
shell
fork
shell
tool
uid=“alice”
exec(“power”)
power
owner=“root”
755 (exec perm)
setuid bit = true
open(“secret”)
read, write…
uid=“root”
creat(“power”)
write(…)
chmod(+x,setuid=true)
uid=“alice”
uid=“root”!!!!
power
Root
(admin/super
user)
secret
owner=“root”
Amplify/escalate the
privilege of processes
running this trusted
program (using
setuid bit).
A trusted program: sudo
Alice
log in
login
fork
setuid(“alice”)
exec
shell
“sudo tool”
fork/exec
uid = 0 (root)
sudo
xkcd.com
fork
exec(“tool”)
With great power comes great responsibility.
tool
uid=“root”
Example: sudo program runs as root, checks
user authorization to act as superuser, and (if
allowed) executes requested command as root.
The secret of setuid
• The setuid bit can be seen as a mechanism for a
trusted program to function as a reference monitor.
• E.g., a trusted program can govern access to files.
– Protect the files with the program owner’s uid.
– Make them inaccessible to other users.
– Other users can access them via the trusted program.
– But only in the manner permitted by the trusted program.
– Example: “moo accounting problem” in 1974 paper (cryptic)
• What is the reference monitor’s “isolation boundary”?
What protects it from its callers?
Reference monitor
requested
operation
“boundary”
protected
state/objects
identity
subject
program
guard
How does the guard decide whether or not to allow access?
We need some way to represent access control policy.
Concept: access control matrix
We can imagine the set of all allowed accesses for
all subjects over all objects as a huge matrix.
obj1
obj2
Alice
RW
---
Bob
R
RW
How is the matrix stored?
Concept: ACLs and capabilities
How is the matrix stored?
ACL
obj1
obj2
Alice
RW
---
Bob
R
RW
capability list
• Capabilities: each subject holds a list of its rights and presents them as
proof of access rights. In many systems, a capability is an unforgeable
reference/token that confers specific rights to access a specific object.
• Access control list (ACL): each object stores a list of identifiers of
subjects permitted to access it.
Concept: roles or groups
roles, groups
wizard
objects
student
obj1
obj2
Alice
yes
no
wizard
RW
---
Bob
no
yes
student
R
RW
• A role or group is a named set S of subjects. Or, equivalently, it
is a named boolean predicate that is true for subject s iff s  S.
• Roles/groups provide a level of indirection that simplifies the
access control matrix, and makes it easier to store and manage.
Attributes and policies
name = “Alice”
wizard = true
Name = “obj1”
access: wizard
name = “Bob”
student = true
Name = “obj2”
access: student
• More generally, each subject/object is labeled with a list of
named attributes with typed values (e.g., boolean).
• Generally, an access policy for a requested access is a
boolean (logic) function over the subject and object attributes.
Unix
file
access
mode
bits
ACLs and Unix file access control
• “Vanilla Unix” supports a limited form of ACL
– read/write/execute for owner/owning-group/other
– Owner can grant access to other users.
– But you can’t grant access to users not in owning-group unless
you grant access to everyone.
– Efficient, but not very expressive.
• It is an example of Discretionary Access Control (DAC).
– Alice can write whatever she wants into her files, and give
anyone she wants access to those files.
• DAC is vulnerable to information leakage.
– What if Alice gives access to her secret file to Bob, and Bob
makes a copy and gives access to Everyone? Can the system
prevent that?
Mandatory Access Control (MAC)
• A MAC system enforces a system-wide information
security policy.
• Requires information flow control: track process data
accesses and disallow “unsafe” flows.
• E.g., if a process reads secret data, don’t let it write into
a network socket that exports data out of the system.
• Classic example:
– Compartmentalize (tag) data by topic/owner and secrecy level.
– Track data flows and label all processes and files with the
(compartment, level) pairs they have “seen” or “may contain”.
– Grant subjects clearance for specific topics at specific levels.
– Disallow flows that don’t comply with the policy.
Information flow and leakage
Bob
Alice
creat(“foo”)
P1
uid=“alice”
write,close
foo
open(“foo”)
read
owner=“alice”
File bar is tainted with Alice’s data, because
process P2 read foo, and the data P2 wrote to
bar could have contained information from foo.
Information flow follows the arrows.
P2
uid=“bob”
creat(“foo”)
P2
write,close
How does a MAC system prevent this?
Track information flow and disallow read access to bar by any process that
does not also have access to foo. Or (alternatively) disallow writes of
“tainted” data out of the system. Works for integrity too! (it’s a dual)
bar
Classic MAC terminology
Dorothy Denning 1976
• Tags represent categories of information.
• The value of a label is a set of tags.
• A set of tags represents an information compartment.
– Containing (potentially) information from multiple categories.
• The set of compartments/labels forms a lattice:
– finite set of elements (e.g., compartments)
– in a partial order (e.g., by subset relation / dominance)
– with a join operator (e.g., to combine two labels)
– and a lower bound called meet (e.g., a label for zero secrecy)
– and a least upper bound (e.g., most secret, maximal join)
26
LATTICE STRUCTURES
Compartments
and Categories
{ARMY, NUCLEAR, CRYPTO}
{ARMY, NUCLEAR}
{ARMY, CRYPTO}
{ARMY}
{NUCLEAR}
{NUCLEAR, CRYPTO}
{CRYPTO}
{}
[Ravi Sandhu, Lattice-Based Access Control Models, 1993]
Lattice
Partial ordered finite set of elements (a poset).
E.g., subsets of a finite set of tags, ordered by subset relation.
Binary join operator.
Set is closed under join.
{A, N, C}
Unique least upper
bound (join)
{A, N}
{A, C}
{N, C}
{A}
{N}
{C}
{}
Unique lower bound (meet)
Using labels
How to prevent an untrusted process from leaking secret data?
P
1. Compare labels to block reads, so it never even sees the data.
P
2. Allow the reads, modify its label to track “taint” by sensitive data,
and compare labels to block writes that leak to untrusted channels.
P
Labels and flow
We can track the flow in mutable labels as information moves.
{A, C}
{A}
join operator
e.g.,union
label S = {}
S = S join {A} = {A}
S = S join {C} = {A,C}
{C}
P
read
P
read
P
P
write
A
C
{A,C}
Clearance and dominance
If labels are fixed, we can use them to apply a safety check to
ensure that information does not flow/leak/trickle “down” the lattice.
{A, C}
{A}
S T  T dominates S
{C}
A flow is safe iff it moves toward a dominating label.
S = {A,C}
P
P
T = {A}
No write down!
Secrecy and integrity
• IFC/MAC works for both secrecy and integrity.
– “Talk only if you’re willing to tell and I’m willing to listen.”
• For secrecy
– An object label classifies the secrecy of its data.
– A subject label grants clearance to read secret data.
– Data flows only “up” (toward a dominating label).
• For integrity
– An object label endorses/certifies the integrity of its data.
– A subject label endorses the subject to produce trusted data.
– Data flows only “down” (toward a dominated label).
Bell-LaPadula (BLP) model (secrecy)
Top Secret
Secret
Confidential
Unclassified
dominance

can-flow
[Ravi Sandhu, Lattice-Based Access Control Models, 1993]
Bell-LaPadula (BLP) model (secrecy)
Axioms
1. No read up
2. No write down (“star” property)
Top Secret
Secret
The labels in a BLP system represent
object classifications and subject
clearances. The system enforces
mandatory access control to block
read/write operations that violate safety.
It applies to any lattice structure.
We can prove inductively that the
system never reaches an unsafe state.
Confidential
Unclassified
Biba model (integrity)
High Integrity
Some Integrity
Suspicious
Garbage
dominance

can-flow
[Ravi Sandhu, Lattice-Based Access Control Models, 1993]
Biba model (integrity)
Axioms
1. No read down
2. No write up (“star” property)
Biba is the dual of BLP for integrity.
Labels represent levels of integrity for
subjects and objects. Subjects may not
corrupt objects with a higher integrity
level, or access information from a lower
integrity level.
High Integrity
Some Integrity
Suspicious
Garbage
36
LATTICE STRUCTURES
Hierarchical
Classes with
Compartments
{A,B}
TS
{B}
{A}
S
{}
product of 2 lattices is a lattice
[Ravi Sandhu, Lattice-Based Access Control Models, 1993]
37
LATTICE STRUCTURES
TS, {A,B}
TS, {B}
TS, {A}
Hierarchical
Classes with
Compartments
TS, {}
S, {A,B}
S, {A}
S, {B}
S, {}
[Ravi Sandhu, Lattice-Based Access Control Models, 1993]
“Decentralized” IFC (DIFC)
• Barbara Liskov (MIT) / Andy Myers [SOSP 1997 and…]
• DIFC is a style of MAC/IFC in which users may define
new tags, and control policy for their tags.
– Users may tag their data.
– Users control who can access their tagged data objects.
– System propagates tags (IFC) and blocks unsafe flows (MAC).
– Trusted programs may be granted authority for tags, allowing
them to mark flows as safe, even if they violate classical IFC.
– E.g., to endorse flows (to vouch for integrity of unsafe flows) or
declassify flows (to vouch for their secrecy).
• New DIFC systems appear at major systems forums
almost every year, e.g., Flume [SOSP 2007].
DIFC Authority
• Trusted subjects may have authority to perform certain
privileged operations on labels.
•
For secrecy
1. Add tag to a process label to enable it to read secret data (and
prevent it from leaking that data).
2. Remove tag from a process label to enable it to write secret data
to an unclassified destination.
3. Remove tag from data label to declassify data.
• Beware: Flume endpoints introduce multiple cases for #3.
DIFC Authority
• Trusted subjects may have authority to perform certain
privileged operations on labels.
• For integrity
1. Add tag to a process label to block it from reading uncertified
data (or loading uncertified code).
2. Add tag to a data label to endorse (certify) data.
• Beware: Flume endpoints introduce multiple cases for #2.
Flume [SOSP 2007]
• DIFC for Unix, no mainline kernel changes.
– Secrecy and integrity labels + reference monitor
– IFC at process grain: can’t track flows “inside” a process.
• All flows pass through channels with endpoints.
– Channels are files, pipes, or sockets: streams.
– An endpoint is a Unix file descriptor. Endpoints have labels.
• Flume API:
– Create tags, control capabilities (authority) to operate on them.
– Change labels for processes, endpoints, files: requires capabilities
to modify affected tags. Label changes are always explicit.
– Create a confined process (spawn) and control its labels and
permissions, and/or pass it pipes and capabilities for tags.
Processes and endpoints
p
Sp = {…}
Ip = {…}
e
Se = {…}
Ie = {…}
Dp = {…}
f
Sf = {…}
If = {…}
Definition 4 (d4) defines
conditions for a safe
endpoint.
Definition 5 (d5) defines
conditions for safe flow.
A Flume process reads and writes data through endpoints. Endpoints
may be readable, or writable, or both.
Endpoints have their own secrecy and integrity labels. Safe flows are
defined between endpoints, based on their labels.
By default an endpoint label is the same as the process label, but the
process may change the endpoint label if it has permission. Adding or
removing a tag from an endpoint label requires dual permission in Dp.
Heart of Flume
What endpoint ops require privilege?
Adding a tag to the secrecy
label of a read endpoint
(declassifies data on read)
Removing a tag from the secrecy
label of a write endpoint
(declassifies data on write)
Removing a tag from the
integrity label of a read endpoint
(allows read of uncertified data)
Adding a tag to the integrity
label of a write endpoint
(certifies on write)
Safe and unsafe flows: scenarios
p
Sp = {…}
Ip = {…}
e
Se = {…}
Ie = {…}
Dp = {…}
f
Definition 4 (d4) defines
conditions for a safe
endpoint.
Sf = {…}
If = {…}
Definition 5 (d5) defines
conditions for safe flow.
We consider all the cases for data movement in or out of p.
It is sufficient to consider the conditions for reading and writing files.
For IPC, the peer q must have the same permission as required to
communicate through a file. (If p writes, then q reads, and vice versa.)
The creator p of a file f assigns a label to f at create time. Process p
may assign any label to f, as long as p is then permitted to write to f
according to the rules. Once assigned the label of f is immutable.
Reading secret data
p
e
P
Sp = {t}
f
d4 condition
Se – Sp  Dp
Se = {t}
Dp = {}
Sf = {t}
d5 condition
Sf  Se
P
P
Process p is tagged with t Sp: p has t-secret data.
File f is tagged with t Sf: f contains t-secret data.
Reads from p on f are safe.
P
The flow is safe even if p is untrusted: p requires no authority to set up
the endpoint e (Dp={}).
It is safe because the data is still marked t-secret at the destination.
Writing secret data
p
e
P
Sp = {t}
f
d4 condition
Sp – Se  Dp
Se = {t}
Dp = {}
Sf = {t}
d5 condition
Se  Sf
P
P
Process p is tagged with t Sp: p has t-secret data.
File f is tagged with t Sf: f contains t-secret data.
Writes from p to f are safe.
P
The flow is safe even if p is untrusted: p requires no authority to set up
the endpoint e (Dp={}).
It is safe because the data is still marked t-secret at the destination.
Export protection
• Create secrecy tag t, give everyone a capability to add it: t+.
• Now any p can read t-secret data by adding t to its Sp.
• But p cannot declassify t-secret data, because p lacks t  Dp.
• Therefore p cannot leak t-secret data: p can read it and write it, but
only to destinations that are also labeled as t-secret.
Blocking leakage of secret data
p
e
f
d4 condition
Sp – Se  Dp
Sp = {t}
Se = {t}
Dp = {...}
Sf = {}
P
d5 condition
Se  Sf
Process p is tagged with t Sp: p has t-secret data.
File f is not tagged: t  Sf: writes of t-secret data to f are unsafe.
To write data, p must either label the destination f as also t-secret, or p
must declassify the data on write (which requires dual privilege on t).
Alternative: read protection
• Create secrecy tag t, and label some data.
• Give a capability for t+ only to selected processes.
• Only processes p with t+ can read the data (by adding t to Sp).
• But p cannot declassify t-secret data if p lacks dual privilege: t  Dp.
Blocking access to secret data
p
e
f
d4 condition
Se – Sp  Dp
Sp = {}
Se = {}
Dp = {}
Sf = {t}
P
d5 condition
Sf  Se
File f is tagged: t  Sf: f contains t-secret data.
Process p is not tagged with t  Sp: reads of t-secret data are unsafe.
To read from f, p must either tag the destination p as also t-secret, or p
must declassify the data on read (which requires dual privilege for t).
Q: is it safe to allow any untrusted process to add t to its secrecy label in
order to read this data?
Writing declassified data
p
e
Sp = {t}
P
f
d4 condition
Sp – Se  Dp
Se = {}
Dp = {t}
Sf = {}
d5 condition
Se  Sf
Process p is tagged with t  Sp: p has t-secret data.
File f is not tagged: t  Sf: writes of t-secret data to f are unsafe.
Endpoint e declassifies data as it is written: t  Se.
Process p is trusted: p requires authority for t to make e (t  Dp).
The flow requires trust in p because the data loses its t-secret tag.
P
P
Reading declassified data
p
e
Sp = {}
P
f
d4 condition
Se – Sp  Dp
Se = {t}
Dp = {t}
Sf = {t}
d5 condition
Sf  Se
P
P
File f is tagged with t  Sf: f contains t-secret data.
Process p is not tagged: t  Sp: reads of t-secret data by p are unsafe.
Endpoint e declassifies data as it reads: t  Se.
Process p is trusted: p requires authority for t to make e (t  Dp).
The flow requires trust in p because the data loses its t-secret tag.
Integrity protection
• Spawn a new process p marked with an integrity tag v  Ip.
• Don’t give p any privilege for v.
• Now p can access only data and code that is certified for v.
Blocking uncertified reads
p
e
f
d4 condition
Ie – Ip  Dp
Ip = {v}
Ie = {v}
Dp = {}
If = {}
d5 condition
If  Ie
Process p is tagged: v  Ip: p is certified as v-assured.
File f is not tagged: v  If: data from f is uncertified (not v-assured).
To read from f, p must either mark itself as not v-assured, or p must
endorse the data on read (which requires dual privilege for v).
Similarly, p cannot execute code from f without reducing p’s integrity.
P
Reading certified data
p
e
f
d4 condition
Ie – Ip  Dp
Ip = {v}
Ie = {v}
Dp = {}
If = {v}
d5 condition
If  Ie
P
P
Process p is tagged: v  Ip: p is certified as v-assured.
File f is tagged: v  If: f contains v-assured data.
Reads from p on f are safe.
The flow is safe even if p is untrusted: p requires no authority to set up
the endpoint e (Dp={}).
It is safe because the data (or code) is certified as v-assured, so it
won’t corrupt p. The data is certified as safe even for a v-assured p.
Blocking uncertified writes
p
e
f
d4 condition
Ie – Ip  Dp
Ip = {}
Ie = {}
Dp = {…}
If = {v}
P
d5 condition
If  Ie
File f is tagged: v  If: f contains v-assured data.
Process p is not tagged: v  Ip: data from p is not certified as v-assured.
To write to f, p must either untag the destination f, or p must endorse the
data on write (which requires dual privilege for v).
Writing certified data
p
e
P
Ip = {v}
f
d4 condition
Ie – Ip  Dp
Ie = {v}
Dp = {}
If = {v}
d5 condition
If  Ie
File f is tagged: v  If: f contains v-assured data.
Process p is tagged: v  Ip: data from p is trusted as v-assured.
Writes from p to f are safe.
P
The flow is safe because p is running v-assured code and all data it
sees is v-assured: p requires no additional authority to set up the
endpoint e (Dp={}).
P
P
Endorsing data on write
p
e
f
d4 condition
Ie – Ip  Dp
Ip = {}
Ie = {v}
Dp = {v}
If = {v}
d5 condition
If  Ie
P
P
File f is tagged: v  If: f contains v-assured data.
Process p is not tagged: v  Ip: data from p is not certified as v-assured.
Endpoint e endorses data as it is written: v  Ie.
Process p is trusted: p requires authority for v to make e (v  Dp).
The flow requires trust in p because the data gains a v-assured tag.
Endorsing data on read
p
e
f
d4 condition
Ie – Ip  Dp
Ip = {v}
Ie = {}
Dp = {v}
If = {}
d5 condition
If  Ie
Process p is tagged: v  Ip: p is certified as v-assured.
File f is not tagged: v  If: data from f is uncertified (not v-assured).
Endpoint e endorses data as it is read: v  Ie.
Process p is trusted: p requires authority for v to make e (v  Dp).
P
P
Flume: stuff to notice
• Example of capability model: processes hold capabilities
for tags, and may transfer them through channels.
– Tokens represent capabilities in transfer and storage. These
are “hard to guess” values, also known as sparse capabilities.
• There’s lots of work in language-level IFC, but Flume
doesn’t do it: no “taint tracking” within a process.
• Section 3.1+3.3 restate BLP/Biba rules for safe flow.
• Reference monitor for confined processes by syscall
interposition (spawn operator, through spawner server).
– E.g., Linux Security Modules (LSM)
• Setlabel: mark trusted programs “like setuid [bit]”.
Reference monitors: three examples
1. The Kernel
2. Setuid bit: a mode bit on an executable program file
indicating that the program always runs as its owner.
– A process running that program always has the owner’s userID.
– Exec* system call implementation retrieves the setuid bit and
owner’s userID from the file’s inode, and sets the process userID
if the setuid bit is set.
3. Server process (as in Flume)
– Listens on a named port, accepts request from clients over
sockets, and decides whether to allow or deny each request.
• For each example, what is the nature of the isolation boundary?
• For each example, how does it identify the subject?