Computer Security Access Control Matrices

1
Computer SecurityAccess Control Matrices

• Fall 2006

Based on slides provided by Matt Bishop for use
with Computer Security Art and Science
Based on adaptations by Carl Gunter
2
Overview

• Access control matrices and state transitions on
  them
• Harrison-Ruzzo-Ullman result
• Corollaries
• Take-Grant Protection Model
• SPM and successors

3
Required

• Reading
• Chapter 2, as needed
• Section 3.1
• Section 3.2 through the proof of Theorem 3-2
• All of Section 3.3 through the paragraph after
  Definition 3-6
• The example in Section 3.3 after Corollary 3-2
• Exercises From 3.9 do 1, 4.

4
Access Control

• Controlling access is a fundamental security
  problem
• Access control policy expresses who is authorized
  to do what
• Read files
• Modify data
• Access services
• Change access

5
Access Control Matrices

• Subjects S s1,,sn
• Objects O o1,,om
• Rights R r1,,rk
• Entries Asi, oj ? R
• Asi, oj rx, , ry means subject si has
  rights rx, , ry over object oj

6
Example 1 File System
7
Example 2 CSL

• Unlock - right to unlock a door
• Log - request entry logs from a door

8
State Transitions

• Change the protection state of system
• represents transition
• Xi ? Xi1 command ? moves system from state
  Xi to Xi1
• Xi Xi1 a sequence of commands moves system
  from state Xi to Xi1
• Commands often called transformation procedures

9
Primitive Operations

• create subject s create object o
• Creates new row, column in ACM creates new
  column in ACM
• destroy subject s destroy object o
• Deletes row, column from ACM deletes column from
  ACM
• enter r into As, o
• Adds r rights for subject s over object o
• delete r from As, o
• Removes r rights from subject s over object o

10
Create Subject

• Precondition s ? S
• Primitive command create subject s

11
Create Object

• Precondition o ? O
• Primitive command create object o

12
Add Right

• Precondition p ? S, y ? O
• Primitive command enter r into ap, y

13
Delete Right

• Precondition p ? S, y ? O
• Primitive command delete r from ap, y

14
Destroy Subject

• Precondition s ? S
• Primitive command destroy subject s

15
Destroy Object

• Precondition o ? O
• Primitive command destroy object o

16
Creating File

• Process p creates file f with r and w permission
• command createfile(p, f)
• create object f
• enter own into Ap, f
• enter r into Ap, f
• enter w into Ap, f
• end

17
Own Right

• Usually allows possessor to change entries in ACM
  column
• So owner of object can add, delete rights for
  others
• May depend on what system allows
• Cant give rights to specific (set of) users
• Cant pass copy flag to specific (set of) users

18
Mono-Operational Commands

• Make process p the owner of file g
• command makeowner(p, g)
• enter own into Ap, g
• end
• Mono-operational command
• Single primitive operation in this command

19
Conditional Commands

• Let p give q r rights over f, if p owns f
• command grantreadfile1(p, f, q)
• if own in Ap, f
• then
• enter r into Aq, f
• end
• Mono-conditional command
• Single condition in this command

20
Multiple Conditions

• Let p give q r rights over f, if p has rights r
  and c over f
• command grantreadfile2(p, f, q)
• if r in Ap, f and c in Ap, f
• then
• enter r into Aq, f
• end

21
Copy Right

• Allows possessor to give rights to another
• Often attached to a right, so only applies to
  that right
• r is read right that cannot be copied
• rc is read right that can be copied
• Is copy flag copied when giving r rights?
• Depends on model, instantiation of model

22
Attenuation of Privilege

• Principle says you cant give rights you do not
  possess
• Restricts addition of rights within a system
• Usually ignored for owner
• Why? Owner gives herself rights, gives them to
  others, deletes her rights.

23
Key Points

• Access control matrix simplest abstraction
  mechanism for representing protection state
• Transitions alter protection state
• 6 primitive operations alter matrix
• Transitions can be expressed as commands composed
  of these operations and, possibly, conditions

24
Proving Safety

• Want to prove system safe or secure
• What does that mean?
• Subjects should only have authorized rights
• E.g. no one except for me can write to my home
  directory
• Easy to check in any given protection state
• What about the dynamic protection system?

25
Formalizing Safety

• Adding a generic right r where there was not one
  is leaking
• If a system S, beginning in initial state s0,
  cannot leak right r, it is safe with respect to
  the right r.
• General property, can simulate
• Leaking a right r on a specific object o
• Leaking r to a subject outside a trusted set

26
Safety Question

• Does there exist an algorithm for determining
  whether a protection system S with initial state
  s0 is safe with respect to a generic right r?
• Here, safe secure for an abstract model

27
General Case

• Answer no
• Sketch of proof
• Reduce halting problem to safety problem
• Turing Machine review
• Infinite tape in one direction
• States K, symbols M distinguished blank b
• Transition function ?(k, m) (k?, m?, L) means
  in state k, symbol m on tape location replaced by
  symbol m?, head moves to left one square, and
  enters state k?
• Halting state is qf TM halts when it enters this
  state

Harrison, Ruzzo, Ullman 76
28
Mapping
1
2
3
4
s1
s2
s3
s4
A
B
C
D

s1
A
own
head
s2
B
own
s3
C k
own
Current state is k
s4
D end
29
Mapping
1
2
3
4
s1
s2
s3
s4
A
B
X
D

s1
A
own
head
s2
B
own
s3
X
own
After ?(k, C) (k1, X, R) where k is the
current state and k1 the next state
s4
D k1 end
30
Command Mapping

• ?(k, C) (k1, X, R) at intermediate becomes
• command ck,C(s3,s4)
• if own in As3,s4 and k in As3,s3
• and C in As3,s3
• then
• delete k from As3,s3
• delete C from As3,s3
• enter X into As3,s3
• enter k1 into As4,s4
• end

31
Mapping
1
2
3
4
5
s1
s2
s3
s4
s5
A
B
X
Y
b
s1
A
own
head
s2
B
own
s3
X
own
After ?(k1, D) (k2, Y, R) where k1 is the
current state and k2 the next state
s4
Y
own
s5
b k2 end
32
Command Mapping

• ?(k1, D) (k2, Y, R) at end becomes
• command crightmostk,C(s4,s5)
• if end in As4,s4 and k1 in As4,s4
• and D in As4,s4
• then
• delete end from As4,s4
• create subject s5
• enter own into As4,s5
• enter end into As5,s5
• delete k1 from As4,s4
• delete D from As4,s4
• enter Y into As4,s4
• enter k2 into As5,s5
• end

33
Rest of Proof

• Protection system exactly simulates a TM
• Exactly 1 end right in ACM
• 1 right in entries corresponds to state
• Thus, at most 1 applicable command
• If TM enters state qf, then right has leaked
• If safety question decidable, then represent TM
  as above and determine if qf leaks
• Implies halting problem decidable
• Conclusion safety question undecidable

34
Mono-Operational Commands

• Answer yes
• Sketch of proof
• Consider minimal sequence of commands c1, , ck
  to leak the right.
• Can omit delete, destroy
• Can merge all creates into one
• Worst case insert every right into every entry
  with s subjects and o objects initially, and n
  rights, upper bound is k n(s1)(o1)

35
Proof Details
36
Detailed Proof Continued
37
Take-Grant Protection Model

• A specific (not generic) system
• Set of rules for state transitions
• Safety decidable, and in time linear with the
  size of the system
• Goal find conditions under which rights can be
  transferred from one entity to another in the
  system

Jones, Lipton, Snyder 76
38
System

• ? objects (files, )
• l subjects (users, processes, )
• ? don't care (either a subject or an object)
• G x G' apply a rewriting rule x (witness) to
• G to get G'
• G G' apply a sequence of rewriting rules
  (witness) to G to get G'
• R t, g, r, w, set of rights

39
Rules
?
?
?
l
l
-
?
?
t
t
take
?
?
?
?
?
?
?
-
grant
g
?
?
g
l
l
40
More Rules
-
?
?
create
l
l
-?
?
?? ?
?
?
l
l
remove
These four rules are called the de jure rules
41
Example Shared Buffer

• Initially s has grant rights for processes p and
  q.
• S sets up a shared buffer for p,q with the
  following steps
• s creates (r,w to new object) b
• s grants (r,w to b) to p
• s grants (r,w to b) to p

42
Symmetry
x
?
y
?
?
l
l
?
?
t
t
?
l
l
z

• x creates (tg to new) v
• z takes (g to v) from x
• z grants (a to y) to v
• x takes (a to y) from v

Similar result for grant
43
Islands

• tg-path path of distinct vertices connected by
  edges labeled t or g
• Call them tg-connected
• island maximal tg-connected subject-only
  subgraph
• Any right one vertex has can be shared with any
  other vertex

44
Example
s
q
t
r
p
s'
?
?
?
?
g
t
t
t
g
g
?
?
?
?
?
y
u
v
x
w
45
canshare Predicate

• Definition
• canshare(r, x, y, G0) if, and only if, there is
  a sequence of protection graphs G0, , Gn such
  that G0 Gn using only de jure rules and in Gn
  there is an edge from x to y labeled r.

46
canshare Properties

• If x and y are subjects in an island, then
  canshare(r, x, y, G0)
• Proof by induction using the properties of
  tg-connected subjects
• General result canshare(r, x, y, G0) is
  decidable using an algorithm of complexity O(V
  E) where V and E are the vertices and edges
  in the graph
• Proof omitted. Sketch given at the end of 3.3.1.

47
Computer SecurityMandatory Access Control

• Fall 2006

Based on slides provided by Matt Bishop for use
with Computer Security Art and Science
48
Confidentiality Policy

• Goal prevent the unauthorized disclosure of
  information
• Deals with information flow
• Integrity incidental
• Multi-level security models are best-known
  examples
• Bell-LaPadula Model basis for many, or most, of
  these

49
Bell-LaPadula Model, Step 1

• Security levels arranged in linear ordering
• Top Secret highest
• Secret
• Confidential
• Unclassified lowest
• Levels consist of security clearance L(s)
• Objects have security classification L(o)

50
Example

• Tamara can read all files
• Claire cannot read Personnel or E-Mail Files
• Ulaley can only read Telephone Lists

51
Reading Information

• Information flows up, not down
• Reads up disallowed, reads down allowed
• Simple Security Condition (Step 1)
• Subject s can read object o iff, L(o) L(s) and
  s has permission to read o
• Note combines mandatory control (relationship of
  security levels) and discretionary control (the
  required permission)
• Sometimes called no reads up rule

52
Writing Information

• Information flows up, not down
• Writes up allowed, writes down disallowed
• -Property (Step 1)
• Subject s can write object o iff L(s) L(o) and
  s has permission to write o
• Note combines mandatory control (relationship of
  security levels) and discretionary control (the
  required permission)
• Sometimes called no writes down rule

53
Basic Security Theorem, Step 1

• If a system is initially in a secure state, and
  every transition of the system satisfies the
  simple security condition, step 1, and the
  -property, step 1, then every state of the
  system is secure
• Proof induct on the number of transitions

54
Bell-LaPadula Model, Step 2

• Expand notion of security level to include
  categories
• Security level is (clearance, category set)
• Examples
• ( Top Secret, NUC, EUR, ASI )
• ( Confidential, EUR, ASI )
• ( Secret, NUC, ASI )

55
Levels and Lattices

• (A, C) dom (A?, C?) iff A? A and C? ? C
• Examples
• (Top Secret, NUC, ASI) dom (Secret, NUC)
• (Secret, NUC, EUR) dom (Confidential,NUC,
  EUR)
• (Top Secret, NUC) ?dom (Confidential, EUR)
• Let C be set of classifications, K set of
  categories. Set of security levels L C ? K, dom
  form lattice
• lub(L) (max(A), C)
• glb(L) (min(A), ?)

56
Levels and Ordering

• Security levels partially ordered
• Any pair of security levels may (or may not) be
  related by dom
• dominates serves the role of greater than in
  step 1
• greater than is a total ordering, though

57
Reading Information

• Information flows up, not down
• Reads up disallowed, reads down allowed
• Simple Security Condition (Step 2)
• Subject s can read object o iff L(s) dom L(o) and
  s has permission to read o
• Note combines mandatory control (relationship of
  security levels) and discretionary control (the
  required permission)
• Sometimes called no reads up rule

58
Writing Information

• Information flows up, not down
• Writes up allowed, writes down disallowed
• -Property (Step 2)
• Subject s can write object o iff L(o) dom L(s)
  and s has permission to write o
• Note combines mandatory control (relationship of
  security levels) and discretionary control (the
  required permission)
• Sometimes called no writes down rule

59
Basic Security Theorem, Step 2

• If a system is initially in a secure state, and
  every transition of the system satisfies the
  simple security condition, step 2, and the
  -property, step 2, then every state of the
  system is secure
• Proof induct on the number of transitions
• In actual Basic Security Theorem, discretionary
  access control treated as third property, and
  simple security property and -property phrased
  to eliminate discretionary part of the
  definitions but simpler to express the way done
  here.

60
Problem

• Colonel has (Secret, NUC, EUR) clearance
• Major has (Secret, EUR) clearance
• Major can talk to colonel (write up or read
  down)
• Colonel cannot talk to major (read up or write
  down)
• Clearly absurd!

61
Solution

• Define maximum, current levels for subjects
• maxlevel(s) dom curlevel(s)
• Example
• Treat Major as an object (Colonel is writing to
  him/her)
• Colonel has maxlevel (Secret, NUC, EUR )
• Colonel sets curlevel to (Secret, EUR )
• Now L(Major) dom curlevel(Colonel)
• Colonel can write to Major without violating no
  writes down
• Does L(s) mean curlevel(s) or maxlevel(s)?
• Formally, we need a more precise notation

62
DG/UX System

• Provides mandatory access controls
• MAC label identifies security level
• Default labels, but can define others
• Initially
• Subjects assigned MAC label of parent
• Initial label assigned to user, kept in
  Authorization and Authentication database
• Object assigned label at creation
• Explicit labels stored as part of attributes
• Implicit labels determined from parent directory

63
MAC Regions
IMPL_HI is maximum (least upper bound) of all
levels IMPL_LO is minimum (greatest lower
bound) of all levels
64
Directory Problem

• Process p at MAC_A tries to create file /tmp/x
• /tmp/x exists but has MAC label MAC_B
• Assume MAC_B dom MAC_A
• Create fails
• Now p knows a file named x with a higher label
  exists
• Fix only programs with same MAC label as
  directory can create files in the directory
• Now compilation wont work, mail cant be
  delivered

65
Multilevel Directory

• Directory with a set of subdirectories, one per
  label
• Not normally visible to user
• p creating /tmp/x actually creates /tmp/d/x where
  d is directory corresponding to MAC_A
• All ps references to /tmp go to /tmp/d
• p cds to /tmp/a, then to ..
• System call stat(., buf) returns inode number
  of real directory
• System call dg_stat(., buf) returns inode of
  /tmp

66
Object Labels

• Requirement every file system object must have
  MAC label
• Roots of file systems have explicit MAC labels
• If mounted file system has no label, it gets
  label of mount point
• Object with implicit MAC label inherits label of
  parent

67
Object Labels

• Problem object has two names
• /x/y/z, /a/b/c refer to same object
• y has explicit label IMPL_HI
• b has explicit label IMPL_B
• Case 1 hard link created while file system on
  DG/UX system, so
• Creating hard link requires explicit label
• If implicit, label made explicit
• Moving a file makes label explicit

68
Object Labels

• Case 2 hard link exists when file system mounted
• No objects on paths have explicit labels paths
  have same implicit labels
• An object on path acquires an explicit label
  implicit label of child must be preserved
• so
• Change to directory label makes child labels
  explicit before the change

69
Object Labels

• Symbolic links are files, and treated as such, so
  
• When resolving symbolic link, label of object is
  label of target of the link
• System needs access to the symbolic link itself

70
Using MAC Labels

• Simple security condition implemented
• -property not fully implemented
• Process MAC must equal object MAC
• Writing allowed only at same security level
• Overly restrictive in practice

71
MAC Tuples

• Up to 3 MAC ranges (one per region)
• MAC range is a set of labels with upper, lower
  bound
• Upper bound must dominate lower bound of range
• Examples
• (Secret, NUC), (Top Secret, NUC)
• (Secret, ?), (Top Secret, NUC, EUR, ASI)
• (Confidential, ASI), (Secret, NUC, ASI)

72
MAC Ranges

• (Secret, NUC), (Top Secret, NUC)
• (Secret, ?), (Top Secret, NUC, EUR, ASI)
• (Confidential, ASI), (Secret, NUC, ASI)
• (Top Secret, NUC) in ranges 1, 2
• (Secret, NUC, ASI) in ranges 2, 3
• (Secret, ASI), (Top Secret, EUR) not valid
  range
• as (Top Secret, EUR) ?dom (Secret, ASI)

73
Objects and Tuples

• Objects must have MAC labels
• May also have MAC label
• If both, tuple overrides label
• Example
• Paper has MAC range
• (Secret, EUR), (Top Secret, NUC, EUR)

74
MAC Tuples

• Process can read object when
• Object MAC range (lr, hr) process MAC label pl
• pl dom hr
• Process MAC label grants read access to upper
  bound of range
• Example
• Peter, with label (Secret, EUR), cannot read
  paper
• (Top Secret, NUC, EUR) dom (Secret, EUR)
• Paul, with label (Top Secret, NUC, EUR, ASI)
  can read paper
• (Top Secret, NUC, EUR, ASI) dom (Top Secret,
  NUC, EUR)

75
MAC Tuples

• Process can write object when
• Object MAC range (lr, hr) process MAC label pl
• pl ? (lr, hr)
• Process MAC label grants write access to any
  label in range
• Example
• Peter, with label (Secret, EUR), can write
  paper
• (Top Secret, NUC, EUR) dom (Secret, EUR) and
  (Secret, EUR) dom (Secret, EUR)
• Paul, with label (Top Secret, NUC, EUR, ASI),
  cannot read paper
• (Top Secret, NUC, EUR, ASI) dom (Top Secret,
  NUC, EUR)