Access Control Theory Practice Nicolas T Courtois University

Access Control Theory => Practice Nicolas T. Courtois - University College London

Comp. Sec COMPGA 01 Roadmap • • • 2 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

Reading 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 • • – • 3 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

Comp. Sec COMPGA 01 Preface 4 Nicolas T. Courtois, January 2009

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

Comp. Sec COMPGA 01 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. 6 – and. T. with additional complexity Nicolas Courtois, January 2009 that does not exist in Unix.

Comp. Sec COMPGA 01 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 7 Nicolas T. Courtois, January 2009

Comp. Sec COMPGA 01 Policies 8 Nicolas T. Courtois, January 2009

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

Comp. Sec COMPGA 01 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. 10 Nicolas T. Courtois, January 2009 Here, it means usually a set of behaviour rules to obey.

Comp. Sec COMPGA 01 W 7 has a “Local Security Policy” Can be edited 11 Nicolas T. Courtois, January 2009

Comp. Sec COMPGA 01 Mechanisms 12 Nicolas T. Courtois, January 2009

Comp. Sec COMPGA 01 Policies and 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. 13 Nicolas T. Courtois, January 2009

Comp. Sec COMPGA 01 Formalization: Sets 14 Nicolas T. Courtois, January 2009

Comp. Sec COMPGA 01 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 10 h 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. 15 Nicolas T. Courtois, January 2009

Comp. Sec COMPGA 01 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. 16 Nicolas T. Courtois, January 2009

Comp. Sec COMPGA 01 More Maths 17 Nicolas T. Courtois, January 2009

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

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

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

Comp. Sec COMPGA 01 Order Relations Order: 1. Reflexive: a a 2. Antisymmetric: if a b and b a then a = b. 3. Transitive a b and b c implies a c. Partial ordering: For any couple a, b we have either a 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 either all pairs are related = a b or b a. mutually comparable 21 Nicolas T. Courtois, January 2009

Comp. Sec COMPGA 01 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 : Ax. A {True, False}. 22 Nicolas T. Courtois, January 2009

Comp. Sec COMPGA 01 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: 23 Nicolas T. Courtois, January 2009

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

Comp. Sec COMPGA 01 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? 25 Nicolas T. Courtois, January 2009

Comp. Sec COMPGA 01 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. 26 Nicolas T. Courtois, January 2009

Comp. Sec COMPGA 01 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 27 Nicolas T. Courtois, January 2009

Comp. Sec COMPGA 01 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 at least 2 symbols: Prove it. 28 Nicolas T. Courtois, January 2009

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

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

Comp. Sec COMPGA 01 Bounds 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. 31 Nicolas T. Courtois, January 2009 u b a v

Comp. Sec COMPGA 01 LUB = Least Upper Bound = Supremum = Sup = Join x 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: a u=a b and say “least upper bound for a and b” or “a Vee b” In La. Te. X vee 32 Nicolas T. Courtois, January 2009 u y b

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

Comp. Sec COMPGA 01 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 La. Te. X wedge 34 Nicolas T. Courtois, January 2009

Comp. Sec COMPGA 01 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 u 2>u. It follows that u 2 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). 35 Nicolas T. Courtois, January 2009

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

Comp. Sec COMPGA 01 Lattices will be on the exam 37 Nicolas T. Courtois, January 2009

Comp. Sec COMPGA 01 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 02 c!!!!!!! 38 Nicolas T. Courtois, January 2009

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

Comp. Sec COMPGA 01 File Access Control 40 Nicolas T. Courtois, January 2009

Comp. Sec COMPGA 01 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: 1. Follow the people: authentication, authorization. 2. Follow the data: 41 information flow control. Nicolas T. Courtois, January 2009

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

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

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

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

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

Comp. Sec COMPGA 01 **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… 47 Nicolas T. Courtois, January 2009

Comp. Sec COMPGA 01 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). 48 Nicolas T. Courtois, January 2009

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

Comp. Sec COMPGA 01 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. 50 Nicolas T. Courtois, January 2009

Comp. Sec COMPGA 01 3 Main Paradigms of Access Control Discretionary Access Control (DAC) • Owners decide about rules, at their discretion, can pass rights on others Mandatory Access Control (MAC) • System-wide policy, possibly denying users full control over the access to resources they created Role-Based Access Control (RBAC) 51 Nicolas T. Courtois, January 2009 frequently combined

Comp. Sec COMPGA 01 Two levels In most policies, • except in pure Mandatory AC policies. Two main levels: • Access Control Policy. – who can access the resources? • Administrative Policy. – who can specify rules and authorizations? And big problem: things change. Ownership can be changed. Permissions can be changed. 52 Nicolas T. Courtois, January 2009

Comp. Sec COMPGA 01 Discretionary Access Control 53 Nicolas T. Courtois, January 2009

Comp. Sec COMPGA 01 What is DAC? DAC policies are a family of access control policies. 1. They enforce the access to files on the basis of • • identity of the requestors explicit access rules: 2. In addition, files have owners • “Discretionary” means: the owner can grant/revoke rights for others 54 Nicolas T. Courtois, January 2009

Comp. Sec COMPGA 01 Matrix Paradigm [Lampson, Graham-Denning, Harrison-Ruzzo-Ullmann] A way to describe mathematically access conditions • A set S of Subjects (Principals). • A set O of Objects (e. g. files). • A set A of Operations. Example: A={read, append, write}. An access control matrix. M=(Mso) s S o O Where each entry Mso A. 55 Nicolas T. Courtois, January 2009

Comp. Sec COMPGA 01 Matrix - Example: S={System, Admin, Bob}. O={exe, doc}. A={read, write, exec, delete}. M= rights Objects S u b j e c t s 56 System Admin Bob m. exe {x, r, w, d} {x} Nicolas T. Courtois, January 2009 a. doc {r, w, d} {w, r, d} {r, w}

Comp. Sec COMPGA 01 Examples: Standard File Systems 57 Nicolas T. Courtois, January 2009

Comp. Sec COMPGA 01 Simple Example - Unix S={Process 1; O={file 2; User 1}. directory 3; process 5; device 6}. A={r, w, exe}. ls -l => the famous “ 9 bits”: 58 Nicolas T. Courtois, January 2009 -rwx-r-x—user group other

Comp. Sec COMPGA 01 Windows NT In comparison - excessively complex, more recent. Required: NTFS, the Microsoft file system designed to work in multi-user environments. Win NT/XP and later. 59 Nicolas T. Courtois, January 2009

Comp. Sec COMPGA 01 DAC in Practice 60 Nicolas T. Courtois, January 2009

Comp. Sec COMPGA 01 Matrices - Implementation Matrix storage: waste of space, not very practical. • Authorization table – sparse matrix kind • Capabilities - rows • Access Control Lists (ACL) - columns 61 Nicolas T. Courtois, January 2009

Comp. Sec COMPGA 01 Matrices - Authorization Tables • Authorization tables, – Commonly used in relational DBMS – Store table of non-null triples (s, o, a). 62 Nicolas T. Courtois, January 2009

Comp. Sec COMPGA 01 Matrices – ACLs and Capabilities • Access Control Lists (ACL) – store M by columns, – together with each object, • Capabilities – store M by rows. – for each user store his capabilities, 63 Nicolas T. Courtois, January 2009 most popular, Unix, Win

Comp. Sec COMPGA 01 In theory… ACLs are widely used (Linux, Windows, etc. ) In theory, Access Control Lists (ACLs) and capabilities represent the same thing. So if we implement ACLs, no need for capabilities. In practice however, they lead to very different systems. 64 Nicolas T. Courtois, January 2009

Comp. Sec COMPGA 01 Managing Permissions • With ACLs, the power to edit the authorities (permissions) is aggregated by resource. • naturally compatible with Discretionary Access Control, owners • With capabilities it will be rather aggregated by Subjects. 65 Nicolas T. Courtois, January 2009

Comp. Sec COMPGA 01 Authentication ACL's: – store rights together with each object, – requires a form of authentication of subjects at the moment of access Capabilities: – for each user store his capabilities, – does not require authentication of subjects: • capabilities are explicit rights in a form of a token, that represents the user’s capabilities. – but require some form of unforgeability + maybe some form control of propagation of capabilities… • token: – now the hacker may try to copy this token from one user to another. So it should be cryptographically signed, and depend on the user’s ID! (some people encrypt capabilities too). 66 Nicolas T. Courtois, January 2009

Comp. Sec COMPGA 01 Fast Access, Review, revocation • ACL's provide faster access, review and revocation on a per-object basis • but if we want to revoke permissions for a particular user, we have to search a whole hard drive… • capabilities provide faster access and review and revocation on a per-subject basis 67 Nicolas T. Courtois, January 2009

Comp. Sec COMPGA 01 Least Privilege • capabilities are better in this respect, • especially for dynamic short-lived subjects created for specific tasks 68 Nicolas T. Courtois, January 2009

Comp. Sec COMPGA 01 Ambient Authority = def = Making a request that only specifies • the names of the object(s) involved and • the operation to be performed on them, is enough for a permitted action to succeed. Þ dominant method today (POSIX ACLs, Windows as well). With capability-based security programs receive also permissions as they might receive data. – this allows programs to determine where the permissions came from. 69 Nicolas T. Courtois, January 2009

Comp. Sec COMPGA 01 The Confused Deputy Problem Definition: The confused deputy problem occurs when one process tricks another process to do an action he doesn’t have permissions to do. Example 1: A compiler is given a permission to write in a directory. The user compiles a program and specifies some very special filename for the output log. So he can overwrite some files he should not have access to. 70 Nicolas T. Courtois, January 2009

Comp. Sec COMPGA 01 Composition of Policies 71 Nicolas T. Courtois, January 2009

Comp. Sec COMPGA 01 Composition of Policies Combine all the benefits of DAC and MAC? Windows and Unix do it. The simplest method: (works like a logical AND) – allow an operation only if all policies implemented allow it. 72 Nicolas T. Courtois, January 2009

Comp. Sec COMPGA 01 Quiz 73 Nicolas T. Courtois, January 2009

Comp. Sec COMPGA 01 Quiz What is a • A security policy for an organisation? For a system? • A “broad” security mechanism? opposite of it? • An order relation (RAT) • Give an example of a totally ordered set. • Give an example of an order that is NOT a total order. • GLB? The dual notion? • Lattice? 74 Nicolas T. Courtois, January 2009