ISA 562 Information System Security

ISA 562 Information System Security Confidentiality Policies Chapter 5 from Bishop’s Book

Overview • Review and background • Review - lattices • Military systems and Denning’s Axioms • Bell-LaPadula (BLP) Policy • Step 1 – clearance/classification • Step 2 – categories • Example System – DG/UX • Tranquility • Controversy

Definition: POset A Poset (Partially ordered set) is a pair (A,<) where A is a set < is a partial order. Thus < is: reflexive: x<x for xeA transitive: x<y and y<z x<z for all x,y,zeA anti-symmetric: x<y and y<x x=y for all x,yeA • Example: A BCD E • < is a total order iffx<y x,yeA A B C

Upper and Lower Bounds of POsets • Definition: (A,<) is a POset and B  A • beA is an upper bound of B iff x<b xeB • ceA is a lower bound of B iff c<x xeB The upper bound b B1, B2, B3 B4 B5 B6 The set B c The lower bound

Supremas and Infimas of POsets Definition: (A,<) is a POset and B  A b0eA is a Least upper bound (aka Supremum) of B iff (1) b0 is an upper bound and (2) b0<b for all other upper bounds b of B b1,b2, b3 b0 • c0eA is a greatest lower bound (Infimum) iff • c0 is an upper bound • c0<b for all other lower bounds c of B Upper bounds B1, B2, B3 B4 B5 B6 The set B c0 c2, c3, c4 Lower bounds

Semi-lattices and Lattices An upper semi-lattice is a POset in which every finite subset has a Supremum • Notation: Join = /\ A lower semi-lattice is a POset in which every finite subset has an Infimum • Notation: Meet = \/ A lattice is a POset that has an upper semi lattice and a lower semi lattice.

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 Special case: Lattice Partial order

Product Lattices 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

Example Product Lattice Lattice 1 (arrow means ) Lattice 2 (arrow means ) Lattice 2  Lattice 1 x,y < x’,y’ means y’ y and x  x’

Military-style system Confidentiality is most important • Integrity/availability important but incidental Users have clearance / files are classified [labeled] • Naturally MAC-centric All information is locked in the system Asssumes: • You won’t memorize something and go outside to tell others • Disclosure is only possible within the system

Information can flow  dominate Military-style system (Cont.) Denning’s Axioms Security classes (clearance and classification) form a lattice

Information Flow • When x reads y, information flows from y to x • When x writes y, information flows from x to y

Overview • Review and background • Lattices • Military systems and Denning’s Axioms • Bell-LaPadula (BLP) Policy • Step 1 – clearance/classification • Step 2 – categories • Example System – DG/UX • Tranquility • Controversy at a glance

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

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

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 • “Read up” not allowed, “read down” allowed • Sometimes called “no read up” rule • Why?: Otherwise subject can get information above their level • Discretionary control may also be present

The *-Property:Preliminary Version *-Property: Subject s can write object o iff L(s) ≤ L(o) “Write up” allowed, “write down” not allowed [“no write down” rule] Why? • Cooperation between foreign agents [spies]

What is Prevented? • Tamara reads personnel files of all spooks working in country X, and then writes them into activity log • Claire reads activity log and sells it to country X [exit spooks] Not possible with *-property

The Basic Security Theorem:The Preliminary 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 • To state and prove this theorem formally: • Need to formalize secure state • Need to formalize state transition

The BLP Model: 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})

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 • Levels are the product lattice

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

The Simple Security Property: The final Version Simple Security Property:Subject s can read object o iff L (s) domL (o) L(s) dom L(o) iff C(s) > C(o) and K(s) > K(o) • Information flows up, not down • “Read up” not allowed, “read down” allowed • Sometimes called no read up rule

The *-Property:The Final Version *-Property:Subject s can write object o iff L(s) domL(o) Information flows up, not down • “Write up” allowed, “write down” not allowed • Sometimes called no write down rule

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

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 a different Id (as a different principle) with reduced clearance • Alias1 (Secret, {NUC, EUR}) • Alias2 (Secret, {EUR})

BLP: Problem • If I can write up, then how about writing files with blanks? • Blind writing up may cause integrity problems, but not a confidentiality breach

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

DG/UX System • A real (and well-regarded) Unix operating system by Data General • Provides mandatory access controls • MAC label identify 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

MAC Regions A&A database , audit Administrati v e Re gion Hierarch y User data and applications User Re gion le v els Site e x ecutables VP1 T rusted data VP2 V irus Pre v ention Re gion VP3 Ex ecutables not part of the TCB VP4 Ex ecutables part of the TCB Reserv ed for future use VP5 Categories • Admin region no write/read except by administrative process • User cannot write to system programs but can read/execute

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 LEAK! • 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

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

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

Overview • Review and background • Review - lattices • Military systems and denning’s Axioms • Bell-LaPadula (BLP) Policy • Step 1 – clearance/classification • Step 2 – categories • Example System – DG/UX • Tranquility • Controversy at a glance

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 is lowered

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 lifetime of the system • Pros and Cons: • Strong tranquility enforces MLS principles, but is inflexible • Weak tranquility moderates restrictions

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

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.” • 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 non-secure and yet self-consistent

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 that rules preserve these 3 properties

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 BLP and is not suitable for a confidentiality policy • Analysts cannot prove “security” definition is appropriate through the model

What Is Modeling? Two types of models • Abstract physical phenomenon to fundamental properties • Begin with axioms and construct a structure to examine the effects of the axioms • BLP Model was developed as a model of the first type • McLean assumed it was developed as a model of the second type

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

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

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

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 • P=e or p=a /* asking for empty or read */ • R=r or p=w and fs(s) dom fo(o) /*asking for read or read/write and the subjects level dominates that of the object */

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 have access to p1,…pn. That is: b(s:p1,..,pn)={oeO| (s,o,p1)eb\/…\/(s,o,pn)eb}

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

ISA 562 Information System Security