Access Control (slides based Ch. 4 Gollmann)

Transcription

1 Access Control (slides based Ch. 4 Gollmann)

2 Preliminary Remarks Computer systems and their use have changed over the last three decades. Traditional multi-user systems provide generic services to their users and do not know about the meaning of files they handle. PC systems support individual users in their jobs. Access operations are complex and application specific. Users are not interested in the details of how their programs are executed. 2

3 Preliminary Remarks This lecture will look at the access control (authorization) part of computer security. Traditional access control as found in operating systems like Windows or Unix. Cover the concepts typically used in defining automated security policies at that level. Keep in mind that these concepts were developed to support organizational policies in closed organizations (enterprises). 3

4 Authentication & Access Control authentication authorization ACL s o principal access request reference monitor object B. Lampson, M. Abadi, M. Burrows, E. Wobber: Authentication in Distributed Systems: Theory and Practice, ACM Transactions on Computer Systems, 10(4), pages ,

5 authorization An active entity, called principal or subject, requests access to a passive entity, called object. authorization: The reference monitor decides whether access is granted or denied. The reference monitor has to find and evaluate the (automated) security policy relevant for the current request. User identities are one of the parameters considered in security policies. 5

6 Principals and Subjects Principal and subject are both used to denote the active entity in an access operation. The word principal has many different meanings and is the source of much confusion. Subjects operate on behalf of human users we call principals, and access is based on the principal s name bound to the subject in some unforgeable manner at authentication time. Because access control structures identify principals, it is important that principal names be globally unique, human-readable and memorable, easily and reliably associated with known people. [M. Gasser, 1990] 6

7 Gollmann s Recommendation Policy: A principal is an entity that can be granted access to objects or can make statements affecting access control decisions. Example: a user ID System: Subjects operate on behalf of (human users we call) principals; access is based on the principal s name bound to the subject in some unforgeable manner at authentication time. Example: a process (running under a user ID) 7

8 Basic Terminology Subject/Principal: active entity user or process. Object: passive entity file or resource. Access operations: vary from basic memory access (read, write) to method calls in an object-oriented system. Comparable systems may use different access operations or attach different meanings to operations which appear to be the same. 8

9 Approaches to authorization Subjects and objects provide a different focus of control (first design principle): What is the principal allowed to do? What may be done with an object? Traditionally, multi-user operating systems manage files and resources, i.e. objects; access control takes the second approach. Application oriented IT systems, like database management systems, direct services to the user and often control actions of principals. 9

10 Access Operations On the most elementary level, a subject may observe an object, or alter an object. With these basic access modes we can express some fundamental policies. For practical purposes a richer set of operations is more convenient. We will give a few examples for richer sets of access operations; note how certain terms are used with different meanings. 10

11 Elementary Access Operations The Bell-LaPadula model (to be covered) has four access rights: execute read append, also called blind write write Mapping between access rights and access modes. observe alter execute append X read X write X X 11

12 Rationale In a multi-user O/S, users open files to get access. Files are opened for read or for write access so that the O/S can avoid conflicts like two users simultaneously writing to the same file. Write access usually includes read access. A user editing a file should not be asked to open it twice. Hence, the write right includes observe and alter mode. Few systems implement append. Allowing users to alter an object without observing its content is rarely useful (exception: audit log). A file can be used without being opened (read). Example: use of a cryptographic key. This can be expressed by an execute right that includes neither observe nor alter mode. 12

13 Multics Multics has access attributes for data segments and access attributes for directory segments; the access attributes are given with their mapping onto the Bell- LaPadula access rights e, r, a, w Data segments read r execute e, r read and write w write a Directory segments status r search e status & modify w append a 13

14 Unix Three access operations: read: from a file write: to a file execute: a file Access operations applied to a directory: read: list contents write: create or rename files in the directory execute: search directory These operations differ from the Bell-LaPadula model. Unix write access does not imply read access. Moral: Do not use your own intuition when interpreting access operations someone else has defined! 14

15 More Access Rights Policies for creating and deleting files can be expressed by access controls on the directory (Unix) specific create and delete rights (Windows, OpenVMS) Policies for defining security settings such as access rights could be handled similarly: access control on the directory specific rights like grant and revoke Rights in CORBA: get, set, use, manage 15

16 Who Sets the Policy? Security policies specify how principals are given access to objects. Two options for deciding who is in charge of setting the policy: The owner of a resource decrees who is allowed access. Such policies are called discretionary as access control is at the owner s discretion. A system wide policy decrees who is allowed access. Such policies are called mandatory. Warning: There exist other interpretations of discretionary and mandatory. 16

17 Access Control Structures Requirements on access control structures: The access control structure should help to express your desired access control policy. You should be able to check that your policy has been captured correctly. Access rights can be defined individually for each combination of subject and object. For large numbers of subjects and objects, such structures are cumbersome to manage. Intermediate levels of control are preferable. 17

18 Access Control Matrix We specify for each combination of subject and object the operations that are permitted. S set of subjects O set of objects A set of access operations Access control matrix: M = (Mso ) s S,o O The matrix entry Mso so A specifies the operations subject s may perform on object o. You can visualize the matrix as a (big) table. 18

19 Access Control Matrix When all your users (principals) are known individually, you can express your policy in an access control matrix, with a row for each principal and a column for each object bill.doc edit.exe fun.com Alice - {exec} {exec,read} Bob {read,write} {exec} {exec,read,write} 19

20 Access Control Matrix continued The access control matrix is an abstract concept, not very suitable for direct implementation, not very convenient for managing security. How do you answer the question: Has your security policy been implemented correctly? Bell-LaPadula (Orange Book): access control matrix defines discretionary access control (DAC). Warning: This use of discretionary differs from the one given some slides earlier. 20

21 Capabilities Focus on the subject: access rights are stored with the subject capabilities rows of the access control matrix Alice edit.exe: {exec} fun.com: {exec,read} Subjects may grant rights to other subjects. Subjects may grant the right to grant rights. How to check who may access a specific object? How to revoke a capability? Distributed system security has created renewed interest in capabilities. 21

22 Access Control Lists (ACLs) Focus on the object: access rights are stored with the object. ACLs columns of the access control matrix. fun.com Alice: {exec} Bill: {exec,read,write} How to check access rights of a specific subject? ACLs are implemented in most commercial operating systems but their actual use is limited. Referring to individual users in a policy works best within organisations. A management overhead has to be paid. 22

23 Groups Alice and Bob are students in a large class; the lecturer wants to give students access to some documents; Entering all names into several ACLs is tedious so the lecturer defines a group, declares the students to be members of the group, and puts the group into the ACLs Access rights are often defined for groups: Unix: owner, group, others 23

24 Groups & Negative Permissions Groups are an intermediate layer between users and objects. users groups objects To deal with special cases, negative permissions withdraw rights users groups objects 24

25 Roles Alternatively, in our example we could have created a role student. Definition: A role is a collection of procedures assigned to users; a user can have more than one role and more than one user can have the same role. The lecturer would create a procedure for reading course material and assign this procedure to the role student. A role course tutor could be assigned a procedure for updating documents. 25

26 Role Based Access Control (RBAC) Procedures: high level access operations with a more complex semantic than read or write; procedures can only be applied to objects of certain data types. Example: funds transfer between bank accounts. Roles are a good match for typical access control requirements in business. RBAC typical found at the application level. 26

27 More on RBAC We use intermediate levels of control to increase simplicity; RBAC can also be used in ways that complicate matters Role hierarchies may refer to hierarchies of positions (superior subordinate) and to hierarchies of access rights; these two hierarchies need not correspond. Separation of duties is an important security principle; there are numerous flavours of static and dynamic separation of duties policies. 27

28 Role Based Access Control The term RBAC itself does not have a generally accepted meaning, and it is used in different ways by different vendors and users. [R. Sandhu, D. Ferraiolo, and R. Kuhn: The NIST Model for Role-Based Access Control: Towards a Unified Standard, Proceedings of the 5th ACM Workshop on Role-Based Access Control, Berlin, Germany, July 26-27, 2000] 28

29 Intermediate Controls Intermediate controls facilitate better security management. To deal with complexity, introduce more levels of indirection. users roles procedures data types objects 29

30 Intermediate Controls Several intermediate concepts can be inserted between subjects and objects Roles: collection of procedures assigned to users. Procedures: high level access control methods with a more complex semantic than read or write; procedures can only be applied to objects of certain data types. Data types: each object is of a certain data type and can be accessed only through procedures defined for this data type. 30

31 Protection Rings Each subject (process) and each object is assigned a number, depending on its importance, e.g. 0 operating system kernel 1 operating system 2 utilities 3 user processes These numbers correspond to concentric protection rings, with ring 0 in the centre giving the highest degree of protection. If a process is assigned the number i, then we say the process runs in ring i. Access control decisions are made by comparing the subject s and object s numbers. 31

32 Protection Rings Protection rings are mainly used for integrity protection. 32

33 Structuring Access Control Some resources in an academic department can be accessed by all students, other resources only by students in a particular year. The department creates groups like All- Students and Y1-Students. The two groups are related, Y1-Students is a subgroup of All-Students; if All-Students has access to a resource, so has Y1-Students. There is no such direct relationship between Y1- Students and Y2-Students. 33

34 Partial Orderings We now can use comparisons in security policies: Is the user s group a subgroup of the group permitted to access this resource? Some groups are related but others are not (e.g. Y1-Students and Y2-Students). Relationships are transitive: CS101-Students Y1-Students All-Students In mathematical terms, we are dealing with a partial ordering. 34

35 Mathematical Definition A partial ordering ( less or equal ) on a set L is relation on L L that is reflexive: for all a L, a a transitive: for all a,b,c L, if a b and b c, then a c antisymmetric: for all a,b L, if a b and b a, then a=b If a b, we say b dominates a or a is dominated by b. 35

36 Examples Integers with the relation divides by : We can order 3 and 6 (3 divides 6) but we cannot order 4 and 6. Integers with the relation ( less or equal ): We can order any two elements (total ordering). Strings with the prefix relation: We can order AA and AABC (AA is a prefix of AABC) but not AA and AB. Power set P(C) with the subset relation : We can order {a,b} and {a,b,c} ({a,b} {a,b,c}) but not {a,b} and {a,c}. 36

37 Example: VSTa Microkernel Groups in Unix are defined by their group ID and are not ordered VSTa uses (cap)abilities to support hierarchies: VSTa (cap)ability is a list of integers.i 1.i 2..i n, e.g..1,.1.2,.1.2.3,.4, Abilities are ordered by the prefix relation: a2 is a prefix of a 1 (written as a 2 a 1 ) if there exists a 3 so that a 1 = a 2 a 3 The empty string ε is the prefix of any ability For example: but not.1.4! 37

38 Abilities and our Example Assign abilities to groups: All-students:.3 Y1-Students:.3.1 CS101-Students: CS105-Students Label objects with appropriate abilities Policy: access is given if the object s label is a prefix of the subject s label; CS101-Students have access to objects labelled or.3.1 or.3 but not to objects labelled

39 Null Values Consider the dual of the previous policy: access is granted if the subject s ability is a prefix of the ability of the object. A subject without an ability has access to every object. Frequent problem: when an access control parameter is missing the policy is not evaluated and access is granted. NULL DACL problem in Windows: nobody has access to a file with an empty ACL but everyone has access to a file with no ACL. 39

40 Towards Lattices In our example, how should we label objects that may be accessed both by CS101-Students and CS105-Students? Answer:?? How should we label a subject that may access resources earmarked for CS101-Students and resources earmarked forcs105-students? Answer:?? To answer both questions, we need more structure than just partial orderings. 40

41 Towards Lattices The slide on lattices to remember Assume that a subject may observe an object only if the subject s label is higher than the object s label. We can ask two questions: Given two objects with different labels, what is the minimal label a subject must have to be allowed to observe both objects? Given two subjects with different labels, what is the maximal label an object can have so that it still can be observed by both subjects? A lattice is a mathematical structure where both questions have unique best answers. 41

42 Lattice (L, ) The slide on lattices you must not memorize A lattice (L, ) is a set L with a partial ordering so that for every two elements a,b L there exists a least upper bound u L: a u, b u, and for all v L: (a v b v) u v a greatest lower bound l L: l a, l b, and for all k L: (k a k b) k l. Lattices come naturally whenever one deals with hierarchical security attributes. 42

43 System Low and System High A label that is dominated by all other labels is called System Low. A label that dominates all other labels is called System High. System Low and System High need not exist; if they exist, they are unique. When L is a finite set, the elements System Low and System High exist. 43

44 Lattices Example 1 The natural numbers with the ordering relation divides by form a lattice: The l.u.b. of a,b is their least common multiple. The g.l.b. of a,b is their greatest common divisor. There exists an element System Low: the number 1. There is no element System High. 44

45 Lattices Example 2 The integers with the ordering form a lattice: The l.u.b. of a,b is the maximum of a and b. The g.l.b. of a,b is the minimum of a and b. Elements System Low and System High do not exist. (The integers with the ordering are a total ordering). 45

46 Lattices Example 3 (P({a,b,c}), ), i.e. the power set of {a,b,c}, with the subset relation as partial ordering least upper bound: union of two sets greatest lower bound: intersection of two sets {a,b,c} {a,b} {a,c} {b,c} {a} {b} {c} {} Lines indicate the subset relation 46

47 Multi-level Security A partial ordering of security labels is used in multi-level ( military ) security (MLS). Mandatory security policies: Subjects and objects are assigned security labels. No read up : a subject may observe an object only if the subject s label dominates the object s label. No write-down : a subject may alter an object only if the subject s label is dominated by the object s label. Trusted as in Trusted Unix or Trusted Solaris usually indicates MLS support. 47

48 Multi-level Security Security policy for protecting classified information: Documents are assigned security levels. The user s clearance dictates which documents the user may read. Mandatory access control policies (MAC) and multi-level security policies of the Orange Book use security levels and adapt these policies to IT systems. In their most elementary version, these policies refer to a linearly ordered hierarchy of four security levels, unclassified, confidential, secret, top secret. 48

49 Basic Security Levels top secret secret confidential unclassified 49

50 Compartments With the basic security levels, we cannot restrict access to documents relating to a secret project X just to people working on X; anyone at level secret would have access. To state need-to-know policies that control access to the resources of specific projects, the following lattice of security levels was introduced: H is a set of classifications with a linear ordering H. C is a set of categories, e.g. project names, company divisions, academic departments, etc. A compartment is a set of categories. A security label (security level) is a pair (h,c), where h H is a security level and c C is a compartment. The partial ordering of security labels is defined by (h1,c 1 ) (h 2,c 2 ) if h 1 H h 2 and c 1 c 2. 50

51 Example Compartments private, {PER,ENG} private, {PER} private, {ENG} private, {} public, {PER,ENG} public, {PER} public, {ENG} public, {} 51

52 Summary Security terminology is ambiguous. Access control has to remain manageable. More sophisticated policies draw you into mathematics. Today we have covered classical access control; we return to current trends later. 52

53 Further Reading Denning, D.E.: Cryptography and Security, Addison- Wesley, 1982 Lampson, B., Abadi, M., Burrows, M., Wobber, E.: Authentication in Distributed Systems: Theory and Practice, ACM Transactions on Computer Systems, vol. 10, 1992, pages Sandhu, R.S. and Coyne, E.J. and Feinstein, H.L. Youman, C.E.: Role-Based Access Control Models, IEEE Computer, vol. 29, February 1996, pages Sandhu, R.S.: Lattice-Based Access Control Models, IEEE Computer, vol. 26, November 1993, pages