1. 1 Review for Exam 1 First Six Chapters of Bishop The nature of the exam: 4-5 questions Similar to the homework. Pseudo-code, modeling, etc.

2. 2 Review Chapter 1 + Transparency CIA of Information Security What they are Given a set of requirements, can we categorize them? Access control matrix Safe state Safe state written as a (pre-condition, post condition) pair of read, write and access operations Add/delete rights Add/delete subjects, objects and operations

3. 3 Review Chapter 1 Continued … Mono Operational Commands Single operations like add “make P the owner of file Q” Written formally as make.owner(p,q) Conditional commands “If p owns f, then let p give r rights to q” How to write them formally Multiple conditions…

4. 4 Review of Chapter 2: Foundations ACM, ACL and capabilities Turing machines Un-decidability HRU Result: Is there an algorithm, that given an initially safe state halts and say yes/no to the safety after granting a generic right r ? Method: Encode safety, granting rights etc as Turing machine instructions Special cases are decidable: Take-grant model

5. 5 Review of Chapter 2: Foundations Details of the Take-grant model Sharing: Characterizing sharability Initial spans, final spans and islands. Recall: subject-only Definition: an island is a maximal tg-connected subject-only sub- graph Lemma: right processed by any vertex in an island can be shared with any other vertex subject endpoints Definition: a bridge is a tg-path between two subject endpoints associated with its word. Observation: rights can be transferred from one end point to another in a bridge Theorem: subject-can-share( ,x,y,G 0 ) is true iff x and y are subjects with an edge from x to y There is a subject s ∈ G 0 with s-to-y edge labeled  There are island I 1,…,I n such that x ∈ I 1 s ∈ I n and with a bridge I j,…,I j+1.

6. 6 Review of Chapter 2: Foundations Details of the Take-grant model Stealing: Characterizing steal-ability The owner does not grant some rights over an object to other subjects, But some of those subjects can get those right indirectly!

7. 77 An Example of Stealing Can-steal( ,S,W,G 0 ) U grants (t to V) to S Owner of  to W grants (t to V) to S S takes (t to U) from V S takes (  to W) from U The owner U of stolen rights  grants other rights to another subject (t rights to V are granted to S) S U g  t t V W

8. 88 Characterizing can-steal Theorem: can-steal( ,X,Y,G 0 ) is true iff 1. ∄ an  labeled  edge from X to Y in G 0, 2.  subject vertex X’= X or X’ initially spans to X 3.  vertex S∈G with an  label to Y in G 0 satisfying can- share(t,X’,S,G 0 ) Observation: to steal, there must be a tg-path through which the thief can share! X thief X S   can-share X’ initially spans Y

9. 9 Review of Chapter 2: Foundations Capability based systems Lock and key model Lock=object, key=subject Object carries permissions = subject presents key to unlock object

10. 10 Review of Chapter 3: Policies Formalization of security policy using precise policy languages DAC, MAC and RBAC Specification of DAC using subjects objects and access rights

11. 11 Example Policies DETL XACML Need to be able to write policies Analyze given policies.

12. 12 DTEL Syntax (Cont ’ d) Characterize every domain as a sequence. First component is a list of programs that can begin in the domain Other elements consists of a Set of writes An arrow A type domain d_admin = (/usr/bin/sh, /usr/bin/csh, /usr/bin/ksh), (crwxd->t_generic), (crwxd->t_readable, t_writable, t_dte, t_sysbin), (sigtstp->d_daemon); Notation: Create (c), Read (r), Write (w), Directory search (d) Only administrator processes can write to system binaries; others cannot The last line says a process in d_admin can suspend a daemon process

13. 13 A Low level Policy Language A low level policy language: Set of inputs to a set of commands Access to X11 display controlled by a list List says what hosts allowed, disallowed access xhost +groucho -chico Connections from host groucho allowed Connections from host chico not allowed Properties of the syntax Allows permissions (+) and prohibitions (-) Issues: Consistency and completeness

14. 14 XACML: Access Control in XML Defined by an OASIS Technical Committee XACML is a markup language for specifying access control language to XML formatted documents Default Language to specify access control policies on the WWW. Policies are evaluated using a set of algorithms Sun provides a reference implementation

15. 15 XACML: Access Control in XML Policies are defined hierarchically using 3 levels At the highest level are policy sets Next Level are policies Last level are rules Policies and Policy Sets have “targets” used to locate the policy by the XACML runtime. The runtime uses Xpath like algorithms to search for a “target match” The access control decisions are evaluated bottom-up Return Values=Permit, Deny, Inapplicable, Error

16. 16 <Rule RuleId="" Effect="Permit"> John can open the door. An XACML Rule

17. 17 <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">John <SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" DataType="http://www.w3.org/2001/XMLSchema#string"/> Details of the Subject

18. 18 door Details of the Resources

19. 19 Review: MAC 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

20. 20 Supremas and Infimas of POsets Definition: (A,<) is a POset and B  A Say that b 0  A is a Least upper bound (aka Supemum) of B iff (1) b 0 is an upper bound and (2) b 0 <b for all other upper bounds b of B B1, B2, B3 B4 B5 B6 b1,b2, b3 b0 Upper bounds Lower bounds C0 C2, C3, C4 The set B Say that c 0  A is a greatest lower bound (Infimum) iff (1) c 0 is an upper bound (2)c 0 <b for all other lower bounds c of B

21. 21 Example Lattices – Power Set Lattice S = {a,b,c} 2 S = { ,{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

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

23. 23 BLP Rules Simple Security Policy No Read up * Security Property No write down

24. 24 BLP and McLean’s Controversies The contribution of the safety theorem needs to be understood properly. Is is purely an inductive definition McLean showed that another property, namely † property also can be used in the proof. Consequence: safe states leak information!

25. 25 Multics Implementation of BLP Has many classes of rules: Operations: Get-read, give read etc. Can write these operations so that BLP rules of *, SS and DS are satisfied.

26. Integrity Policies Chapter 6 BIBA Clark and Wilson Lipner’s lattice 26

27. 27 Strict Integrity policy: The Biba Model If BLP prevents information from flowing down (disclosed) Then BLP-upside-down will prevent information from flowing up (getting corrupted) Top Secret Secret Confidential Unclassified  or dominate information flow High Integrity Some integrity Suspicious Garbage  or dominate information flow BLP Biba

28. 28 BLP Upside-down BLP=read-down and write-up, so BLP upside-down = Biba model BIBA= read-up and write-down Top Secret Secret Confidential Unclassified information flow High Integrity Some integrity Suspicious Garbage information flow BLP Biba write read write read

29. 29 Information Flow Result If there is any information transfer path from o 1  O to o n+1  O, then strict integrity policy implies that i (o n+1 ) ≤ i (o 1 ) holds for all n  1. No object can be corrupted, either directly (write up) or indirectly (first read down then write equal) o1o1 o2o2 o3o3 O n+1 s1s1 s2s2 s3s3 …… SnSn OnOn read write high integrity low integrity

30. 30 Subject Low Water Mark Policy Idea: s can read down, but once it does, its integrity level drops (so it cannot corrupt other objects) Example: After a machine reads emails infected with worm, the machine is no longer trusted and isolated Rules: For any s  S and o  O 1. s r o and s reads o implies i (s) = min(i (s), i (o)) 2. s w o iff i (o) ≤ i (s) (write-down) 3. s x s 2 iff i (s 1 ) ≤ i (s 2 ) (execute-up)

31. 31 Object Low-Water-Mark Policy Idea: s can write up, but the integrity level of any object o that is written by s writes will drop Example: After a virus is detected, whatever files written by the virus are no longer trusted and deleted Rules: For any s  S and o  O 1. s r o iff i (s) ≤ i (o) (read-up) 2. s w o and s writes o implies i (o) = min(i (s), i (o)) 3. S x s 2 iff i (s 1 ) ≤ i (s 2 ) (execute-up)

32. 32 The Information Flow Result Theorem: With the subject/object low-water-mark policy, the information flow result also holds. That is i (o n+1 ) ≤ i (o 1 ) holds in the following cases: o1o1 o2o2 s1s1 readwrite o1o1 o2o2 s1s1 subject low-water-mark policy prevents s 1 from corrupting o 2 o1o1 o2o2 s1s1 o1o1 o2o2 s1s1 object low-water-mark policy detects the corruption of o 2

33. 33 Combining Biba and BLP Important: security levels (BLP) and integrity levels (Biba) are two different things BLP: MLS Access control Biba: Integrity Whether they overlap with each other purely depends on applications When they do overlap, the enforcement of BLP and Biba may conflict What if they are exactly the same? – a homework problem in the textbook!

34. 34 The Lattice (Lipner’s Lattice) S:Repair S:Production Users O:Production Data S:Application Programmers O:Development Code and Data S:System Programmers O:System Code in Development O:Repair Code O:System Programs O:Production Code O:Tools S:System Managers O:Audit Trail S:System Control LEGEND S:Subjects O:Objects LEGEND S:Subjects O:Objects Only 9 out of 192 labels are used

35. 35 How The Elements Interact TPs CDIs USERS UDIs IVPs Verify integrity Transform: valid  valid