CMSC 414
Computer and Network Security
Lecture 13
Jonathan Katz
Announcement
 Midterm exam Oct. 28, covering material through
Oct. 21
2
Access control
3
Some terminology
 Protected entities: “objects” O
 Active objects: “subjects” S (i.e., users/processes)
– Note that subjects can also be objects
– Typically, each subject associated with some
principal/owner
• In identity-based access control, security policies ultimately
refer to the human users who are the principals
 Subjects/objects can be:
– Files
– Processes
– Functions/variables (within a program)
– System resources (servers, printers, etc.)
4
Access control
 Determining who has access to specific files, or
other system resources
subject
request
reference allow/deny
object
monitor
5
Secure mediation
 Security kernel, Trusted Computing Base (TCB)
– Responsible for implementing the reference monitor
 Must be tamper-resistant
 Must be ‘impossible’ to circumvent
– I.e., all access to objects must be mediated by the TCB
 Ideally, small and simple enough that it can be
tested and analyzed so as to ensure correctness
6
Authentication vs. authorization
 Authentication
– Determining the identity of a user
– May also involve verification of IP address, machine,
time, etc…
– Determine whether a user is allowed to access the
system at all
– Used for audit, not just authorization
– We will return to this later; for now we assume it
 Authorization
– Assuming identity of user is known, determine whether
some specific action is allowed
7
General principles
 Fine-grained access control is better
– E.g., control access to files not just directories
 Least privilege
– Grant minimum abilities necessary to complete task
 Closed vs. open policies
– Closed = disallowed unless explicitly allowed
– Open = allowed unless explicitly disallowed
8
Access control matrix
 Matrix indexed by all subjects and objects
– Characterizes rights of each subject with respect to each
object
 Formally: set of objects O and subjects S, set of
possible rights
 Matrix A with subjects labeling the rows and
objects labeling the columns
– The entry (s,o) contains the rights for s on o
– Examples: read/write/execute/etc.
9
Example
Objects
Subjects
File 1
File 2
User 1
{r,w}
{w}
User 2
{w}
{w}
File 3
…
File n
{r,w}
{r,w}
User 3
{r}
{w}
{r}
{w}
…
User k
{r}
{r}
{r,w}
10
Access control matrix
 The access control matrix provides a useful way to
think about the rights in the system
 It can also be a way to implement access control
subject
request
reference allow/deny
object
monitor
11
More complex access control
 In general, “rights” may be functions
– “Actual” rights depend on the system state
– Equivalently, may depend on system history
 Rights can form hierarchies
– E.g., right X implies right Y
 How fine-grained the access control is depends on
how fine-grained the rights are
– E.g., “write” vs. “append-only”
12
Coarse-grained access control
 Access control can also be more coarse-grained
than a full-blown access matrix would imply
 E.g., in unix:
– For a file, specify access rights for the owner, the group
to which the owner belongs, and everyone else
– Possible rights are: read, write, execute
13
Drawbacks of access control matrix
 Number of subjects/objects is very large
 Most entries blank/default
 One central matrix modified every time
subjects/objects are created/deleted or rights are
modified
 “Small’ change can result in “many” changes to
the access control matrix
– E.g., making a file publicly readable
14
Access control lists (ACLs)
 Can be viewed as storing the columns of the
access control matrix with the appropriate object
 Ideally, one list per object showing all subjects
with access and their rights
– Missing subjects given “default” access
– Easy to make an object public
15
Access control lists, pictorially
object
subject
request
reference allow/deny
object
monitor
S1: {r, w}
S2: {w}
S3: {r, w}
S4: {}
object
16
ACLs in practice
 Again, full granularity may not be supported
 E.g., unix allows permissions set for the owner of
the file, the group to which the owner belongs, and
everyone else (all)
17
Conflicts?
 Need a mechanism for handling conflicts
 E.g., what if group has fewer rights than all?
 Resolution (in unix)
if user = owner then owner permission
else if user in group then group permission
else all permission
 In general, could have been done differently
18
Capabilities
 Can be viewed as storing the rows of the access
control matrix with the appropriate subject
– Analogy: user has a “ticket” which grants access to an
object
– A capability is an unforgeable token giving user access
to an object and describing the level of allowable access
– Capabilities can specify new types of rights
19
Capabilities: two approaches
 Ticket is held by the OS, which returns to the
subject a pointer to the ticket
 Ticket is held by the user, but protected from
forgery by cryptographic mechanisms
– How?
– Ticket can then be verified by the OS, or by the object
itself
20
Capabilities, pictorially
I have the
right
to read O1
S1
request
reference allow/deny
monitor
O1
21
ACLs vs. capabilities
 Access control list
– ACL associated with each object
– Upon request, check user/group against the ACL
– Relies on authentication of the user
 Capabilities
– Can be passed from one user/process to another
– Upon request, check validity of capability
• No need to know the identity of the user/process making the
request
22
ACLs vs. capabilities
 How would delegation be handled using ACLs vs.
using capabilities?
– ACL: run process using the name of the caller, or OS
can explicitly support delegation
– Capabilities: allow delegation “for free”
 How can a user make a file public when
capabilities are used?
– Maybe it’s a good thing that this is hard to do!
23
Example use of capabilities
 From “The Confused Deputy,” by Hardy
 Compiler in directory SYS
– User can provide file for debugging output
– Compiler writes statistics to SYS/stat
• Compiler allowed to write to SYS
 User set debugging file to SYS/billing
– Allowed…
– The effect was to overwrite the billing file!
24
Example continued…
 Underlying problem: authority from two sources:
static + authority of caller
– The problem was not the compiler having the wrong
authority, but exercising its authority for the wrong
purpose
 How to solve this problem?
– Check filenames explicitly?
• They can change…
• Legitimate access to SYS files…
– Add specific list of conditions?
• Complexity grows
– Straightforward use of ACLs does not work… (why?)
25
Suggested solution
 Use capabilities:
– Give compiler capability to write to SYS/stat
• Compiler does not even need to be aware of the filename it is
writing to; the capability takes care of this
– Caller can provide additional capabilities, as needed
– Compiler must explicitly designate capabilities to use in
a particular situation
• In this case, will designate the capabilities presented by the
caller!
26
More advantages of capabilities
 When a subject holds a capability for an object, it
knows it has access to that object
– In contrast, with ACLs it is impossible for a subject to
obtain a list of all files it is allowed to read
 Capabilities allow finer-grained treatment of
subjects
– E.g., at the process level rather than the user level
– Why can’t this be done with ACLs?
 Capabilities allow easier delegation
– In ACLs, usually all-or-nothing (if allowed at all)
– With capabilities, can delegate a subset of the rights
you have
27
Advantages of capabilities
 Better at enforcing “principle of least privilege”
– Provide access to minimal resources, to the minimal set
of subjects
28
Confinement myth
 Myth: Capabilities can be delegated “at will” and
therefore cannot be confined
 Mistaken assumption that the ability to write/read
files translates into the ability to read/write
capabilities
– Capabilities are not “just” files; they can be typed by
the OS
 Can be set up so that A can delegate a capability to
B only if A is authorized to pass capabilities to B
29
Revoking capabilities
 Revocation is more difficult with capabilities than
with ACLs…
 One solution: indirection
– Capabilities name an entry in a table, rather than the
object itself
– To revoke access to object, invalidate the entry in the
table
– Difficult to revoke access of a single user
 Capabilities can also expire with time
 If OS stores capabilities, can delete upon request
– Requires object to recall to whom capabilities given
30
Disadvantages of capabilities
 Overhead
 Revocation more difficult
 Controlling delegation more difficult
 Making files world-readable more difficult
(impossible?)
31
Access control policies
32
Access control policies
 Discretionary access control (DAC)
 Mandatory access control (MAC)
 Role-based access control (RBAC)
 Not necessarily mutually exclusive
– A system may use different mechanisms for different
resources
– Or, apply two policies; allow access only if both allow
33
DAC
 Controls based on the identity of the user and
access rules
 Rights can be delegated at users’ discretion
 Most common
34
MAC
 Controls based on comparing security labels with
security clearances
 Delegation not allowed
 Primarily used in military environments
35
RBAC
 Controls based on a user’s (or program’s) role, not
their identity
 User’s rights can change depending on their
current role
 More recent proposal
36
Discretionary access control
37
Discretionary access control
 Access control rights determined (to some extent)
by users themselves, not by the system
– I.e., users ‘own’ certain resources, and can decide who
has access to them and not
 E.g., chmod in unix
38
Delegation (one approach)
 We augment the access control matrix to include
subjects as objects
– A[S,S] = “control” always
– When S creates S’, a new column and row is created;
A[S,S’] is set to “control”
 Rights on other objects can also come with or
without a “copy flag” set
– Allows delegation, either with or without delegation of
copy flag
– Denote by adding ‘*’ to the right
39
Delegation (by S)
 Delegate {r, r*} on X to S’ by S allowed if any of
the following hold
– A[S,X] = r* (i.e., S has right r on X, and copy flag set)
– A[S,X] = “owner” (i.e., S owns X)
– A[S,X] = r and A[S,S’] = “control” (i.e., S has right r
on X, and S created S’)
 Delete {r} on X from S’ by S allowed if any of the
following hold
– A[S,X] = “owner”
– S[S,S’] = “control”
40
Creating a new subject
 When S creates S’, why not populate row S’ with
the same access rights that are in row S?
– Least privilege…
41
Note
 The OS can be treated as a subject with all rights
 Examples
– When Alice logs in do:
• Create shell process p with rights appropriate for Alice
• Delegate ownership of p to Alice
– When Alice creates a file
• OS creates file f
• OS delegates {own, read, write} to Alice on file f
42