# handout4

Document Sample

```					ISA 662 Information System Security

Confidentiality Policies
Chapter 5

1
Overview
   Review and background
   Review - lattices
   Military systems and Denning’s Axioms
   Step 1 – clearance/classification
   Step 2 – categories
   Example System – DG/UX
   Tranquility
   Controversy at a glance

2
POsets
   Definition: A Poset (short hand for Partially Ordered Set)
is a pair (A,<) where
   A is a set
   < is a partial order. That is
   < is reflexive: x<x for xeA
   < is transitive: x<y and y<z x<z for all x,y,zeA
   < is anti-symmetric: x<y and y<x x=y for all x,yeA
   Example:                        A
A
B       C        D
B
E
   < is a total order iff x<y x,yeA                              C

3
Upper and Lower Bounds of POsets
   Definition: (A,<) is a POset and B  A
   Say that beA is an upper bound of B iff x<b xeB
   Say that ceA is a lower bound of B iff c<x xeB

The upper bound     b

B1, B2,
The set B
B3 B4 B5 B6

The lower bound      c

4
Supremas and Infimas of POsets
    Definition: (A,<) is a POset and B  A
 Say that b0eA is a Least upper bound (aka Supemum)

of B iff (1) b0is an upper bound and (2) b0<b for all
other upper bounds b of B
b1,b2, b3      Say that c0eA is a
Upper bounds                b0          greatest lower
bound (Infimum) iff
B1, B2,        (1) c0 is an upper
bound (2)c0<b for
The set B
B3 B4 B5 B6       all other lower
bounds c of B

C0
Lower bounds         C2, C3, C4
5
Semi-lattices and Lattices
   Definition
   An upper semi-lattice is a POset in which every
finites subset has a Supremum
   Notation: Join = /\
   A lower semi-lattice is a POset in which every finites
subset has an Infimum
   Notation: Meet = \/
   A lattice is a POset that is an upper semi lattice and a
lower semi lattice.

6
Example Lattices – Power Set Lattice
   S = {a,b,c}
   2S = { ,{a},{b},{c},{a,b},{b,c},{a,c},{a,b,c} }
   Arrows mean  (informally, included by)
Special case: Total order   Partial order    Special case: Lattice
a,b,c             a,b,c
a,b,c

a,b       b,c   a,b    b,c     a,c
a,b

a                    a           c   a       b      c

                

7
Product Lattices
   Definition: Let (L1, <1, /\1, \/1) and
(L2, <2, /\2, \/2) be two lattices. Then the
product lattice is defined as: (L,<,/\,\/) where:
    L = L1 x L2
   That is L ={(x,y): xeL1 and yeL2}
   (x,y) < (a,b) iff x <1 a and y <2 b

8
Example Product Lattice
ab,2
a,2                 b,2
ab
2                                       ,2

a            b               ab,1

1                                a,1                 b,1
Lattice 1                                ,1
(arrow means )        Lattice 2
Lattice 2  Lattice 1
(arrow means )
x,y < x’,y’ means
y’  y and x  x’
9
Background
   Military-style system
   Confidentiality is the most important
   Integrity/availability incidental
   Users with clearance / files classified
   Naturally MAC-centric
   All information locked in a system
   You won’t memorize something and go outside to tell others
   Disclosure is only possible within the system

10
Background (Cont’d)
   Denning’s Axioms
   Security classes (clearance/classification) form a
lattice
Top Secret
Information
can flow                                   {EUR,US}

Secret           {EUR }       { US}


Confidential
dominate

Unclassified                            11
Overview
   Review and background
   Lattices
   Military systems and Denning’s Axioms
   Step 1 – clearance/classification
   Step 2 – categories
   Example System – DG/UX
   Tranquility
   Controversy at a glance

12
The Preliminary Version
   Security levels are linearly ordered (say L)
   Top Secret: highest
   Secret
   Confidential
   Unclassified: lowest
   Subjects and Objects assigned a level in the linear order
   Subjects: Levels are called security clearance L(s)
   Objects: Levels are called security classification L(o)
   Formally they are mapping into L:
   Ls: Subjects  L
   Lo: Subjects  L

13
An Example
security level       subject      object
Top Secret           Tamara       Personnel Files
Secret               Samuel       E-Mail Files
Confidential         Claire       Activity Logs
Unclassified         Ulaley       Telephone Lists

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

14
The Simple Security Property:
The Preliminary version
Simple Security Property: Subject s can read
object o iff, L(o) ≤ L(s)

   Information flows up, not down
   Sometimes called “no reads up” rule
   Why?: Otherwise subject can get information
that are at a higher level
   Discretionary control is also present but will not
be mentioned for simplicity
15
The *-Property:
Preliminary Version

*-Property: Subject s can write object o iff
L(s) ≤ L(o)

   Information flows up, not down
   “Writes up” allowed, “writes down” disallowed
   Sometimes called no writes down rule
   Why?: If allowed, can result in making higher level
information available to lower level subjects
   Discretionary control is also present but will not be
mentioned for simplicity
16
Information Flow
   When x read y, information flows from y to x
   When x write y, information flows from x to y

17
What is to be Prevented
security level      subject      object
Top Secret          Tamara       Personnel Files
Secret              Samuel       E-Mail Files
Confidential        Claire       Activity Logs
Unclassified        Ulaley       Telephone Lists

   Tamara reads personnel files of all spies working in X
country, and then writes them into activity logs
   Claire reads activity logs and sells the data to X country

No longer possible with *-property
18
The Basic Security Theorem:
The Preliminary Version
If a system is initially in a secure state, and
every transition of the system satisfy the

1. simple security condition, and
2. the *-property

Then every state of the system is secure

What is required to state and prove this theorem formally?
1. Need to formalize secure state
2. Need to formalize state transition
19
The final version
   Expand notion of security level to include
categories
   Based on the need to know principle
   Security level is (clearance, category set)
   Example:
   ( Top Secret, { NUC, EUR, ASI } )
   ( Confidential, { EUR, ASI } )
   ( Secret, { NUC, ASI } )
   (unclassified {NUC})

20
Security Levels as a Product Lattice
   (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                               ab,2
a,2               b,2
   Levels are the product lattice              ,2
ab,1
a,1            b,1
,1            21
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
   Total ordering is a special lattice

22
The Simple Security Property:
The final Version
Simple Security Property: Subject s can read
object o iff L(s) dom L(o)

   L(s) dom L(o) iff C(s) > C(o) and K(s) > K(o)
   Information flows up, not down
   Sometimes called no reads up rule

23
The *-Property:
The Final Version
*-Property: Subject s can write object o
iff L(o) dom L(s)

   Information flows up, not down
   “Writes up” allowed, “writes down” disallowed
   Sometimes called no writes down rule

24
The Basic Security Theorem:
The Final Version

If a system is initially in a secure state, and
every transition of the system satisfies

(1) the simple security condition, and
(2) the *-property

Then
every state of the system is secure
25
Applying BLP: Example 1

   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”)
   Interferes with functionality!
   Colonel is a user, and he can login with different
Id (as a different principle) with a reduced
clearances
   Alias1 (Secret, {NUC, EUR})
   Alias2 (Secret, {EUR})
26
BLP: Problem

   If I can write up, then how about writing files
with blanks?
   Blind writing up may cause integrity problems, but
not confidentiality breaches
   Will cover in next lecture

27
Key Points
   Confidentiality models restrict flow of
information
   Bell-LaPadula (BLP) models multilevel security
   Cornerstone of much work in computer security
   Simple security property says no read up and *-
property says no write down
   Both ensure information can only flow up

28
DG/UX System
   A real (and probably well-regarded) Unix
operating system by Data General
   Provides mandatory access controls
   MAC label identifies security level
   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 the set of) attributes
   Implicit labels determined from parent directory

29
MAC Regions

Hierarchy     User data and applications              User Region
levels
VP1    Site executables
VP2    Trusted data                  Virus Prevention Region
VP3    Executables not part of the TCB
VP4    Executables part of theTCB
VP5    Reserved for future use
Categories

•User cannot write to system programs but can read/execute

30
A Directory Problem
   Process p at MAC_A tries to create file /tmp/x
   If /tmp/x exists but has MAC label MAC_B where MAC_B
dom MAC_A
   Create must fail:
   Now p knows a file named x with a higher label exists
   Solution: only programs with same MAC label as
directory can create files in the directory
   If this was only way to create files, them /tmp would
have problems.
   For example, compilation, mail won’t work
   Solution: Multi-level directory

31
DG B2-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 p’s references to /tmp go to /tmp/d
   p cd’s to /tmp/a, then to ..
   System call stat(“.”, &buf) returns inode number of
real directory
   System call dg_stat(“.”, &buf) returns inode of /tmp

32
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

33
Overview
   Review and background
   Review - lattices
   Military systems and denning’s Axioms
   Step 1 – clearance/classification
   Step 2 – categories
   Example System – DG/UX
   Tranquility
   Controversy at a glance

34
Principle of Tranquility
   Raising object’s security level
   Information once available to some subjects is no
longer available
   Usually assume information has already been
accessed, so this does nothing
   Lowering object’s security level
   The declassification problem
   Essentially, a “write down” violating *-property
   Solution: define set of trusted subjects that
sanitize or remove sensitive information before
security level lowered

35
Types of Tranquility
   Strong Tranquility
   The clearances of subjects, and the classifications of
objects, do not change during the lifetime of the
system
   Weak Tranquility
   The clearances of subjects, and the classifications of
objects, do not change in a way that violates the
simple security condition or the *-property during the

Pros and Cons:
Strong tranquility enforces MLS principles, but are inflexible
Weak tranquility moderates restrictions
36
Example
   DG/UX System
   Only a trusted user (security administrator) can lower
object’s security level
   In general, process MAC labels cannot change
   If a user wants a new MAC label, needs to initiate new
process
   Cumbersome, so user can be designated as able to change
process MAC label within a specified range

37
Controversy
   McLean:
   “value of the BLP is much overrated since there is a
great deal more to security than it captures. Further,
what is captured by the BST is so trivial that it is
hard to imagine a realistic security model for which it
does not hold.”
   Basis: given assumptions known to be non-secure,
BST can prove a non-secure system to be secure
   He invented a completely reversed version of BLP,
which is clearly non-secure and yet self-consistent

38
Discussion
   The Basic Security Theorem show that obeying
stated rules preserve security
   Key question: what is security?
   Bell-LaPadula defines it in terms of 3 properties
(simple security condition, *-property, discretionary
security property)
   Theorems are assertions about these properties
   Rules describe changes to a particular system
instantiating the model
   Showing system is secure requires proving rules
preserve these 3 properties

39
Rules and Model
   Nature of rules is irrelevant to model
   Model treats “security” as axiomatic
   Policy defines “security”
   This instantiates the model
   Policy reflects the requirements of the systems
   McLean’s definition differs from Bell-LaPadula
   … and is not suitable for a confidentiality policy
   Analysts cannot prove “security” definition is
appropriate through the model

40
Response: What Is Modeling?
   Two types of models
1.   Abstract physical phenomenon to fundamental
properties
2.   Begin with axioms and construct a structure to
examine the effects of those axioms
   Bell-LaPadula Model developed as a model in
the first sense
    McLean assumes it was developed as a model in
the second sense

41
Towards Proving the
Basic Security Theorem
   System security state: (b,m,f,h)
   b e P(SxOxP): Rights that may be exercised
   m e M: AC Matrix of the current state
   f e F: Current subject and object clearances + categories
   h e H: Current hierarchy of objects
   R: Requests
   D = {y, n, I (illegal) e (error)} : outputs
   V: set of states
   W  R x D x V x V : set of runs
   RN, DN, VN : sequences of requests, answers, states
   S (R,D,W,z0): a run of the system
42
Example: State 1, and transition
 L ={high, low}, K={all}
 S={s}, O={o}, P={r, w}

 For every f e F, fc(s)=(high,{all}) or (low,{all})

 For every f e F, fo(o)=(high,{all}) or (low,{all})

Changes to
 S={s,s’}, (s’,w,o) e m1

 Before writing s’ writing, b1 does not change

43
Example: processing requests
   Suppose s’ requests r1 to write to o: succeed
   Transition from v0 to v1=(b2,m1,f1) where
   b2={(s,o,r),(s’,o,w)} so x=r1,y=yes,z-(vo,v1)

   S request r2, writing to o: denied, so
   x=(r1,r2)
   Y=(yes, no)
   Z=(v0,v1,v2) where v2=v1

44
The Simple Security Property

   Simple Security Property: (s,o,p) e SxOxP
satisfies the simple security property relative to
f (written scc REL f ) iff

   R=r or p=w and fs(s) dom fo(o)
dominates that of the object */

45
Some more notation
   A state satisfies the simple security condition if
all elements of B satisfy the simple security
condition
   Define b(s:p1,..,pn) the set of all objects that
b(s:p1,..,pn)={oeO| (s,o,p1)eb\/…\/(s,o,pn)eb}

46
The *- Property

   *-Property: (b,m,f,h) satisfy  seS
 b(s:a)≠ø  oeO b(s:a) fo(o) dom fc(s)

 b(s:w)≠ø  oeO b(s:w) fo(o) = fc(s)

 b(s:r)≠ø  oeO b(s:r) fc(s) dom fo(s)

Says:
•If a subject can write an object, then the objects classification
dominates that of the subject clearance (write up)
•If a subject can also read then they must be the same
•If a subject can read then subject clearance must dominate
objects classification
47

```
DOCUMENT INFO
Shared By:
Categories:
Stats:
 views: 3 posted: 4/30/2011 language: English pages: 47