CSCE 201 Introduction to Information Security Fall 2010 Access Control Models

CSCE Farkas2 Reading assignments Required: – An Introduction to Computer Security: The NIST Handbook, : Chapter 17, LOGICAL ACCESS CONTROL, pages – Microsoft support, Use access control to restrict who can use your files, 2001, 2005, ol.mspx ol.mspx Recommended: – Sudhakar Govindavajhala and Andrew W. Appel, Windows Access Control Demystied, 2006, – Ravi Sandhu, Edward Coyne, Hal Feinstein and Charles Youman, Role- Based Access Control Models, IEEE Computer, Volume 29, Number 2, February

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

CSCE 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

CSCE 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

CSCE 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

Mandatory Access Control ( Mandatory Access Control (review only)

CSCE 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)

CSCE 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})

CSCE 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})

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

CSCE 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

CSCE 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

CSCE 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.

CSCE 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

Role-Based Access Control (RBAC)

CSCE 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

CSCE 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

CSCE 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.

CSCE 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

CSCE Farkas21 RBAC RBAC 3 consolidated model RBAC 1 role hierarchy RBAC 2 constraints RBAC 0 base model

CSCE Farkas22 RBAC U Users R Roles P Permissions. S Sessions User assignment Permission assignment

CSCE 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

CSCE 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

CSCE 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

RBAC1, 2, and 3 review only

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

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

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

CSCE 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

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

CSCE Farkas32 RBAC 2 – Components Same as RBAC 0 + Constraints

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

CSCE 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

CSCE Farkas35 RBAC 2 Constraints can apply to sessions, user and roles functions

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

CSCE Farkas37 Next Class Windows XP access control