Access Control Theory => Practice

1. Access ControlTheory => Practice Nicolas T. Courtois - University College London

2. Roadmap • Policies and Mechanisms • Set models, • Maths: Relations, Bounds, Lattices • Reference Monitor model • DAC, Matrix model • DAC in practical OS (slides part 04) Nicolas T. Courtois, January 2009

3. Home reading • Security Policies: Section 2.2.1 discussed in the context of management! • Partial orderings, Lattices: Section 5.8 • Reference Monitor: Section 5.2. + page 88 • Deeper study outside of scope of this course: pages 89-90. • DAC, ownership, matrices, basic rights; Sections 5.3. – 5.5. Nicolas T. Courtois, January 2009

4. Preface Nicolas T. Courtois, January 2009

5. Can We Help? vs. Science insecure rubbish! Nicolas T. Courtois, January 2009

6. History • There is a substantial amount of theory about access control. • When UNIX systems were developed, more or less at the same time, researchers have tried to formalize what access control should be doing… • Influence of pure mathematicians on the topic… • Designers of OS, HTTP servers, database systems etc. have developed highly complex systems, learning from this research, and/or from hacker attacks, Trojans etc. • Windows NT and now commercial security/firewall packages (with lots of detailed controls), and Vista etc. were developed much later. • and with additional complexity that does not exist in Unix. Nicolas T. Courtois, January 2009

7. Is There a Need For Access Control ? The problem of access control remains largely unsolved. And seems almost unsolvable, • OS+add-on security all-in-one security packages will • either decide everything for you, • or leave the customer with choices that nobody understands Nicolas T. Courtois, January 2009

8. Policies Nicolas T. Courtois, January 2009

9. Security Policy: Meaning we want to use: Policy, is what we want. How things should be. Nicolas T. Courtois, January 2009

10. A Security Policy: Short, succinct statement. High-level. Describes what is and what is not allowed.Security and protection requirements, rules, and goals. It defines what it means to be “secure” for a system or organisation/entity. Here, it usually means a set of requirements. Here, it means usually a set of behaviour rules to obey. Nicolas T. Courtois, January 2009

11. W7 has a “Local Security Policy” Can be edited Nicolas T. Courtois, January 2009

12. Mechanisms Nicolas T. Courtois, January 2009

13. Policies and Mechanisms Mechanisms are there to enforce policies. • various sorts of mechanisms, HW, SW, crypto, and combinations… • A policy can be implemented in several different ways, relying on different mechanisms. Nicolas T. Courtois, January 2009

14. Formalization: Sets Nicolas T. Courtois, January 2009

15. A Security Policy – Abstract view Describes what is and what is not allowed. Can be mathematically formalized as follows: All possible “states of the world” P in a system are partitioned into allowed states Q  P and non-allowed states P-Q  P. Beware: in this formulation, these are not merely states of a PC. They need to encompass the user and all the entities in involved. Example: user A is reading the file f at 10h should define a distinct subset of the universe of possible outcomes. A Security Mechanism => May restrict the system to a subset of states R  P. Nicolas T. Courtois, January 2009

16. Secure vs. Precise vs. Broad States allowed by the policy Q  P. States allowed by the mechanism R  P. Def. [Bishop] A mechanism is secure iff R  Q. All that ever happens is acceptable, but certain things could be forbidden for no reason. A mechanism is precise iff R = Q. All that can ever happen is exactly what is allowed. A mechanism is broad iff R  Q – (could be called insecure) Allowing of unwanted or “insecure” states. Nicolas T. Courtois, January 2009

17. More Maths Nicolas T. Courtois, January 2009

18. Relations set of all ordered pairs a_1,a2 Let A be a set. We call relation any subset R  AxA. We write things such as: a R b which reads a is “in relation R” to b Nicolas T. Courtois, January 2009

19. Example of a Relation Let a,b  NI Definition: a | b iff  x NI such that ax=b. Nicolas T. Courtois, January 2009

20. Relations Sub-categories: • equivalence relations, • order relations (orderings), • etc. Nicolas T. Courtois, January 2009

21. Order Relations Order: • Reflexive: a  a • Antisymmetric: if a  b and b  a then a = b. • Transitive a  b and b  c implies a  c. Partial ordering: For any couple a,b we have eithera  b or b  a or neither – when we say that “a and b are unrelated”. Total ordering (= linear order = simple order = chain): 4. For any couple a,b we have eithera  b or b  a. all pairs are related = mutually comparable Nicolas T. Courtois, January 2009

22. POSET = Partially Ordered Set A set A and an order relation . Poset is the couple (A,). Maths view: we write formulas on the board and we use axioms 123 on the last slide to prove theorems. Pragmatic computational functional view of a relation: we have objects a  A data type A 2-ary function called : AxA {True, False}. Nicolas T. Courtois, January 2009

23. Example of a POSET Let a,b  NI Definition: a | b means  x such that ax=b. (NI, |) is a poset • Reflexive: a | a • Antisymmetric: if a | b and b | a then a = b. • Transitive a | b and b | c implies a | c. Proof: But not a total order: Prove it: Nicolas T. Courtois, January 2009

24. Example 2 of a POSET Let  be an alphabet Let * be the set of all strings over . Define Prefix(a,b) formally Nicolas T. Courtois, January 2009

25. Example 2 of a POSET Let  be an alphabet Let * be the set of all strings over . Def: Prefix(a,b) iff  c s.t. a||c=b Theorem: (*, Prefix) is a poset. Proof? Nicolas T. Courtois, January 2009

26. Example 2 of a POSET Let  be an alphabet Let * be the set of all strings over . Def: Prefix(a,b) iff  c in *s.t. a||c=b Theorem: (*, Prefix) is a poset. Relation Prefix is a partial ordering. Nicolas T. Courtois, January 2009

27. Example 2 of a POSET Let  be an alphabet Let * be the set of all strings over . Def: Prefix(a,b) iff  c in *s.t. a||c=b Theorem: (*, Prefix) is a poset. Relation Prefix is a partial ordering. • R • A • T Nicolas T. Courtois, January 2009

28. Example 2 of a POSET Let  be an alphabet Let * be the set of all strings over . Def: Prefix(a,b) iff  c in * s.t. a||c=b Theorem: (*, Prefix) is a poset. Relation Prefix is a partial ordering. • Reflexive: a is a prefix of a • Anti-symmetric: if a is a prefix of b and b is a prefix of a then a = b. • Transitive a is a prefix of b and b is a prefix of c, it implies a is a prefix of c. But not a total order if there are at least 2 symbols: Prove it. Nicolas T. Courtois, January 2009

29. Applications Order relations are useful in formalising and analysing security… Nicolas T. Courtois, January 2009

30. Bounds Exist for both total and partial orders. Total orders are simple in sense they are “one-dimensional”. Like a straight line… Partial orders describe much more complex situations… Nicolas T. Courtois, January 2009

31. Bounds u Definition: u is an upper bound for a and b iff au and bu. Definition: v is an lower bound for a and b iff va and vb. b a v Nicolas T. Courtois, January 2009

32. LUB = Least Upper Bound = Supremum = Sup = Join x y u Definition: u is an upper bound for a and b iff au and bu. Definition: Let U be the set of all upper bounds for a and b. Let u be the smallest element in U, which means  x U we have ux. Then u is called the Least Upper Bound of a and b. We write: u=a  b and say “least upper bound for a and b” or “a Vee b” In LaTeX\vee b a Nicolas T. Courtois, January 2009

33. LUB = Least Upper Bound = Supremum = Sup = Join a  b and we have the dual concept: GLB = Greatest Lower Bound = Infimum = Inf = Meet a  b Nicolas T. Courtois, January 2009

34. LUB = Least Upper Bound = Supremum = Sup = Join a  b and we have the dual concept: GLB = Greatest Lower Bound = Infimum = Inf = Meet a  b defined in the same way… BTW. we say “greatest lower bound for a and b”or “a Wedge b” In LaTeX \wedge Nicolas T. Courtois, January 2009

35. Funny Example  Claim 1: NI, is a total ordering. Proof: check 123+total Claim 2: 1 is the biggest element of NI. Proof: Let u be the biggest integer. #: Assume u>1 (which definition means u1 AND u1). It follows that u2>u. It follows that u2 is even bigger, so u is not the biggest integer. So our Assumption # was wrong. So u1. So u=1 (0 is smaller and must be excluded). Nicolas T. Courtois, January 2009

36. Important Bounds do NOT have to exist. Least upper bounds don’t have to exist either. Nicolas T. Courtois, January 2009

37. Latticeswill be on the exam Nicolas T. Courtois, January 2009

38. Lattices Definition: An ordered set S,  Is called a lattice if: •  a, b the LUB a  b exists. •  a, b the GLB a  b exists. More about lattices later in part 02c!!!!!!! Nicolas T. Courtois, January 2009

39. Example: “Hasse Diagram” Top Secret, {army, nuclear} Top Secret, {army} Top Secret, {nuclear} Secret, {army, nuclear} Top Secret, {} Secret, {nuclear} Secret, {army} Secret, {} Nicolas T. Courtois, January 2009

40. File Access Control Nicolas T. Courtois, January 2009

41. Example of a Security Policy No user should be able to access other user’s files. Benefits: • Accountability • Trace-ability • Confidentiality, Privacy Two methods to implement this, can be combined: • Follow the people: authentication, authorization. • Follow the data: information flow control. Nicolas T. Courtois, January 2009

42. Users, Subjects, Principals User, Principal Subject Me ownership process running as me our book says principals == uniquely and reliably identified human users HOWEVER… can make a distinction: create through authentication and authorization Nicolas T. Courtois, January 2009

43. Distinction Users vs. Principals = def: Unit of Access Control and Authorization One to Many. Principal User login1 Subject Me ownership process running as login2 login2 create through authentication and authorization similar in Java Principal == human readable name Nicolas T. Courtois, January 2009

44. Subjects and Objects User, Principal, Subject reference monitor Object Me ? resource process running as me/login2 process2 access through authorization policy In Unix processes are both subjects and objects, we can execute operations on processes: kill, suspend, resume.. access controloccurs at 2 moments! Nicolas T. Courtois, January 2009

45. Reference Monitor Def: (in OS and software security) module that controls all software access to data objects or devices. exists since Windows NT (XP,Vista). resource reference monitor ? user process access request policy Nicolas T. Courtois, January 2009

46. Reference Monitor Must be: • tamperproof, • always-invoked = non-bypassable = a.k.a. complete mediation • economical, simple • small enough to be build in a rigorous way, • and fully tested and analysed Windows: exists since Windows NT. Nicolas T. Courtois, January 2009

47. **Optional Reading: • At which level/place to implement the Reference Monitor? – Section 6.1.1. More than reference monitor: • TCB = Trusted Computing Base or Security Kernel (very closely related concepts): • like all the protections inside the computer combined together… • combination of hardware and software • fundamental “low layers” of a secure OS… Nicolas T. Courtois, January 2009

48. Technical Difficulties • Residue Channels • Inadvertent or built-in duplication/storage of information. • need to actively clean disk sectors, memory, CPU cache etc. • Covert Channels • information is leaking • intentional or not (side channels). Nicolas T. Courtois, January 2009

49. Access Control Models Formally and mathematically define the access control method. It should be: • Complete • Encompass all our security desiderata. • Consistent. • Free of contradictions. Nicolas T. Courtois, January 2009

50. Access Control Models Benefits: We can formally prove security properties of a system. Derived from basic premises. Nice split between conceptual and practical security: • Prove that model is “secure”. • And that the implementation is correct. Allows to claim that security is achieved. • And if it isn’t, we should be able to blame EITHER the model OR the implementation, without any ambiguity. Nicolas T. Courtois, January 2009