1. CSCE 201 Introduction to Information Security Fall 2010 Access Control Models

2. CSCE 201 - Farkas2 Reading assignments Required: – An Introduction to Computer Security: The NIST Handbook, http://csrc.nist.gov/publications/nistpubs/800-12/handbook.pdf : Chapter 17, LOGICAL ACCESS CONTROL, pages 194 - 207 http://csrc.nist.gov/publications/nistpubs/800-12/handbook.pdf – Microsoft support, Use access control to restrict who can use your files, 2001, 2005, http://www.microsoft.com/windowsxp/using/security/learnmore/accesscontr ol.mspx http://www.microsoft.com/windowsxp/using/security/learnmore/accesscontr ol.mspx Recommended: – Sudhakar Govindavajhala and Andrew W. Appel, Windows Access Control Demystied, 2006, http://www.cs.princeton.edu/~appel/papers/winval.pdfhttp://www.cs.princeton.edu/~appel/papers/winval.pdf – Ravi Sandhu, Edward Coyne, Hal Feinstein and Charles Youman, Role- Based Access Control Models, IEEE Computer, Volume 29, Number 2, February 1996 http://www.list.gmu.edu/journals/computer/i94rbac(org).pdfhttp://www.list.gmu.edu/journals/computer/i94rbac(org).pdf

3. CSCE 201 - Farkas3 3 Access Control Models All accesses Discretionary AC Mandatory AC Role-Based AC

4. CSCE 201 - Farkas4 4 DAC and Trojan Horse Employee Black’s Employee Brown: read, write Black, Brown: read, write Brown Black Read Employee REJECTED! Black is not allowed To access Employee

5. CSCE 201 - Farkas5 5 DAC and Trojan Horse Employee Black’s Employee Brown: read, write Black, Brown: read, write Brown Black Word Processor TH Inserts Trojan Horse Into shared program Uses shared program Reads Employee Copies Employee To Black’s Employee

6. CSCE 201 - Farkas6 6 DAC Overview Advantages: – Intuitive – Easy to implement Disadvantages: – Inherent vulnerability (look TH example) – Maintenance of ACL or Capability lists – Maintenance of Grant/Revoke – Limited power of negative authorization

7. Mandatory Access Control ( Mandatory Access Control (review only)

8. CSCE 201 - Farkas8 Mandatory Access Control Objects: security classification e.g., grades=(confidential, {student-info}) Subjects: security clearances e.g., Joe=(confidential, {student-info}) Access rules: defined by comparing the security classification of the requested objects with the security clearance of the subject e.g., subject can read object only if label(subject) dominates label(object)

9. CSCE 201 - Farkas9 Mandatory Access Control Security Classes (labels): (A,C) A – total order authority level C – set of categories e.g.,A = confidential > public, C = {student-info, dept-info} (confidential,{ }) (confidential,{dept-info}) (confidential,{student-info,dept-info}) (confidential,{student-info}) (public,{student-info,dept-info}) (public,{,dept-info}) (public,{ }) (public,{student-info})

10. CSCE 201 - Farkas10 Mandatory Access Control Dominance (  ): label l=(A,C) dominates l’=(A’,C’) iff A  A’ and C  C’ e.g., (confidential,{student-info})  (public,{student-info}) BUT (confidential, {student-info})  (public,{student-info, department-info})

11. CSCE 201 - Farkas11 Bell- LaPadula (BLP) Model Confidentiality protection Lattice-based access control – Subjects – Objects – Security labels Supports decentralized administration

12. CSCE 201 - Farkas12 BLP Reference Monitor All accesses are controlled by the reference monitor Cannot be bypassed Access is allowed iff the resulting system state satisfies all security properties Trusted subjects: subjects trusted not to compromise security

13. CSCE 201 - Farkas13 BLP Axioms 1. Simple-security property: a subject s is allowed to read an object o only if the security label of s dominates the security label of o – No read up – Applies to all subjects

14. CSCE 201 - Farkas14 *-property: a subject s is allowed to write an object o only if the security label of o dominates the security label of s No write down Applies to un-trusted subjects only BLP Axioms 2.

15. CSCE 201 - Farkas15 Trojan Horse and BLP Employee Black’s Employee Brown: read, write Black, Brown: read, write Brown Black Word Processor TH Insert Trojan Horse Into shared program Use shared program Read Employee Copy Employee To Black’s Employee Secret Public Secret  Public Public Secret Reference Monitor

16. Role-Based Access Control (RBAC)

17. CSCE 201 - Farkas17 RBAC Motivation Multi-user systems Multi-application systems Permissions are associated with roles Role-permission assignments are persistent v.s. user-permission assignments Intuitive: competency, authority and responsibility

18. CSCE 201 - Farkas18 Motivation Express organizational policies – Separation of duties – Delegation of authority Flexible: easy to modify to meet new security requirements Supports – Least-privilege – Separation of duties – Data abstraction

19. CSCE 201 - Farkas19 RBAC Allows to express security requirements but CANNOT ENFORCE THESE PRINCIPLES e.g., RBAC can be configured to enforce BLP rules but its correctness depend on the configuration done by the system security officer.

20. CSCE 201 - Farkas20 Roles User group: collection of user with possibly different permissions Role: mediator between collection of users and collection of permissions RBAC independent from DAC and MAC (they may coexist) RBAC is policy neutral: configuration of RBAC determines the policy to be enforced

21. CSCE 201 - Farkas21 RBAC RBAC 3 consolidated model RBAC 1 role hierarchy RBAC 2 constraints RBAC 0 base model

22. CSCE 201 - Farkas22 RBAC 0.... U Users R Roles P Permissions. S Sessions User assignment Permission assignment

23. CSCE 201 - Farkas23 RBAC0 User: human beings Role: job function (title) Permission: approval of a mode of access – Always positive – Abstract representation – Can apply to single object or to many

24. CSCE 201 - Farkas24 RBAC 0 UA: user assignments – Many-to-many PA: Permission assignment – Many-to-many Session: mapping of a user to possibly may roles – Multiple roles can be activated simultaneously – Permissions: union of permissions from all roles – Each session is associated with a single user – User may have multiple sessions at the same time

25. CSCE 201 - Farkas25 RBAC 0 Permissions apply to data and resource objects only Permissions do NOT apply to RBAC components Administrative permissions: modify U,R,S,P Session: under the control of user to – Activate any subset of permitted roles – Change roles within a session

26. RBAC1, 2, and 3 review only

27. CSCE 201 - Farkas27 RBAC 1.... U Users R Roles P Permissions. S Sessions User assignment Permission assignment Role Hierarchy

28. CSCE 201 - Farkas28 RBAC 1 Structuring roles Inheritance of permission from junior role (bottom) to senior role (top) Partial order – Reflexive – Transitive – Anti-symmetric

29. CSCE 201 - Farkas29 RBAC 1 Role Hierarchy Primary-care Physician Specialist Physician Health-care provider Inheritance of privileges

30. CSCE 201 - Farkas30 RBAC 1 Limit scope of inheritance Project Supervisor Test Engineer Programmer Project Member Test Engineer’ Test Engineer Programmer Programmer’ Project Member Project Supervisor Private Roles

31. CSCE 201 - Farkas31 RBAC 2 – Constraints Enforces high-level organizational policies Management of decentralized security Constraints define “acceptable” and “not acceptable” accesses

32. CSCE 201 - Farkas32 RBAC 2 – Components Same as RBAC 0 + Constraints

33. CSCE 201 - Farkas33 RBAC 2.... U Users R Roles P Permissions. S Sessions User assignment Permission assignment Constraints

34. CSCE 201 - Farkas34 RBAC 2 Mutually exclusive roles Dual constraint of permission assignments (permission assigned to at most one mutually exclusive role) Cardinality constraints (e.g., # of roles an individual can belong) Prerequisite roles

35. CSCE 201 - Farkas35 RBAC 2 Constraints can apply to sessions, user and roles functions

36. CSCE 201 - Farkas36 RBAC 3.... U Users R Roles P Permissions. S Sessions User assignment Permission assignment Constraints

37. CSCE 201 - Farkas37 Next Class Windows XP access control