CMSC 414
Computer and Network Security
Lecture 10
Jonathan Katz
HW review: private-key encryption
 What is the definition of an encryption scheme?
– Is a ciphertext that is longer than the plaintext allowed?
 How does CTR mode work?
– What is the ciphertext?
 What is a reasonable definition of security for an
encryption scheme?
HW review --- problem 3
Discretionary access control
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.
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}
Delegation (one approach)
 We augment the access control matrix to include
subjects as objects
– A[S,S] = “control” always
– A[S,S’] = “control” if S created S’
– 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 w/o delegation of
copy flag
– Denote by *
Delegation (by S)
 Delegate {r, r*} on X to S’ allowed if any of the
following hold
– A[S,X] = r* (S has right r on X, and copy flag set)
– A[S,X] = “owner” (S owns X)
– A[S,X] = r and A[S,S’] = “control” (S has right r on X,
and S created S’)
 Delete {r} on X from S’ allowed if any of the
following hold
– A[S,X] = “owner”
– S[S,S’] = “control”
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…
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
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
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
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)
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
Capabilities
 Can be viewed as storing the rows of the access
control matrix with the appropriate subject
 Some burden for implementing protection placed
on the user rather than just the OS
– 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
Capabilities: two approaches
 Ticket is held by 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…?
– Two possibilities: ticket verified by the object or by the
OS itself
• Who holds the key in each case…?
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
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 is a good thing that this is hard to do!
 How to revoke capabilities?
– See later…
Example use of capabilities
 From “The Confused Deputy,” by Hardy
 Compiler in directory SYS
– User can provide file for debugging output
– Compiler can write statistics to SYS/stat
• Compiler given ability to write to SYS
 User set debugging file to SYS/billing
– Allowed…
– Overwrote billing file!
Example continued…
 Underlying problem: authority from two sources:
static + authority of caller
 How to solve this problem?
– Check filenames explicitly?
• They can change…
• Legitimate access to SYS files…
– Add specific list of conditions?
• Complexity grows
– ACLs do not work… (why?)
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