1. CSCE Access Control

2. Midterm Exam Midterm is open book, online exam.
It is individual work, you cannot share or discuss the answers with any other student. Plagiarism, cheating, copying from online sources will be penalized.
You have 1 hour 30 minutes to write the midterm (allowing extra time to print and scan documents if needed). If you have special accommodation that permits additional time for the exam, please notify me ASAP.
CSCE Farkas

3. Midterm Process On October 19 at 2:45 pm the Midterm quiz open
Follow the link to the downloadable midterm
If you print the midterm than
hand-write your answers
Scan your answers as a single .pdf file.
Else
type your answers to the .doc file
save it as a .pdf file.
Name your file as <last name_initialoffirstname>.pdf
Upload your .pdf file into the dropbox assignment for Midterm Answers by 4:15 pm. Late submissions: -5 points/minute
CSCE Farkas

4. Reading Reading for this lecture: Required: Pfleeger: Ch. 2.2
Recommended:
S. De Capitani di Vimercati, P. Samarati, S. Jajodia: Policies, Models, and Languages for Access Control, in Databases in Networked Information Systems, Volume 3433 of the series Lecture Notes in Computer Science pp ,
CSCE Farkas

5. Access Control
Access control: ensures that all direct accesses to object are authorized
Protects against accidental and malicious threats by regulating the reading, writing and execution of data and programs
Need:
Proper user identification and authentication
Information specifying the access rights is protected form modification
CSCE Farkas

6. Access Control Requirement
Cannot be bypassed
Enforce least-privilege and need-to-know restrictions
Enforce organizational policy
CSCE Farkas

7. Access Control
Protection objects: system resources for which protection is desirable
Memory, file, directory, hardware resource, software resources, etc.
Subjects: active entities requesting accesses to resources
User, owner, program, etc.
Access mode: type of access
Read, write, execute
CSCE Farkas

8. Access Control Access control components:
Access control policy: specifies the authorized accesses of a system
Access control mechanism: implements and enforces the policy
Separation of components allows to:
Define access requirements independently from implementation
Compare different policies
Implement mechanisms that can enforce a wide range of policies
CSCE Farkas

9. System Architecture and Policy
Simple monolithic system
Distributed homogeneous system under centralized control
Distributed autonomous systems homogeneous domain
Distributed heterogeneous system
Complexity Of
Policy
CSCE Farkas

10. Closed v.s. Open Systems Closed system Open System yes no no yes
(minimum privilege)
(maximum privilege)
Access requ.
Access requ.
Allowed
accesses
Disallowed
accesses
Exists Rule?
Exists Rule?
yes no no
yes
Access
permitted
Access
denied
Access
permitted
Access
denied
CSCE Farkas

11. Negative Authorization
Traditional systems: Mutual exclusion
New systems: combined use of positive and negative authorizations
Support exceptions
Problems: How to deal with
Incompleteness – Default policy
Inconsistencies – Conflict resolution
CSCE Farkas

12. Conflict Resolution Denial takes precedence
Most specific takes precedence
Most specific along a path takes precedence
Priority-based
Positional
Grantor and time-dependent
Single strategy vs. combination of strategies
CSCE Farkas

13. Policy Specification Language
Express policy concepts
Required properties of policy languages:
Support access control, delegation, and obligation
Provide structuring constructs to handle large systems
Support composite policies
Must be able to analyze policies for conflicts and inconsistencies
Extensible
Comprehensible and easy to use
CSCE Farkas

14. Policy Development Policy maker: Start with high-level policies
Refine high-level policies to low-level policy specification
Determine resources required to satisfy the policy
Translate high-level policies into enforceable versions
Support analysis that verifies that lower level policies actually meet the needs of higher level ones.
CSCE Farkas

15. Authorization Management
Who can grant and revoke access rights?
Centralized administration: security officer
Decentralized administration: locally autonomous systems
Hierarchical decentralization: security officer > departmental system administrator > Windows NT administrator
Ownership based: owner of data may grant access to other to his/her data (possibly with grant option)
Cooperative authorization: predefined groups of users or predefined number of users may access data
CSCE Farkas

16. Access Control Models All accesses Discretionary AC DAC Mandatory AC
Role-Based AC
RBAC
CSCE Farkas

17. Discretionary Access Control
Access control is based on
User’s identity and
Access control rules
Most common administration: owner based
Users can protect what they own
Owner may grant access to others
Owner may define the type of access given to others
CSCE Farkas

18. Access Matrix Model OBJECTS AND SUBJECTS File 1 File 2 S U B J E C T
Read
Write
Own
Joe
Sam
CSCE Farkas

19. Implementation Access Control List (column) (ACL)
File 1 File 2
Joe:Read Joe:Read
Joe:Write Sam:Read
Joe:Own Sam:Write
Sam:Own
Access Control List (column)
(ACL)
Capability List (row)
Joe: File 1/Read, File 1/Write, File 1/Own, File 2/Read
Sam: File 2/Read, File 2/Write, File 2/Own
Subject Access Object
Joe Read File 1
Joe Write File 1
Joe Own File 1
Joe Read File 2
Sam Read File 2
Sam Write File 2
Sam Own File 2
Access Control Triples
CSCE Farkas

20. ACL vs. Capabilities ACL: Capabilities: Per object based
Good for file systems
Capabilities:
Per subject based
Good for environment with dynamic, short-lived subjects
CSCE Farkas

21. Access Control Conditions
Data-dependent conditions: access constraints based on the value of the accessed data
Time-dependent: access constraints based on the time of the data access
Context-dependent: access constraints based on combinations on data which can be accessed
History-dependent: access constraints based on previously accessed data
CSCE Farkas

22. DAC and Trojan Horse Brown: read, write Employee Read Employee
REJECTED!
Black is not allowed
To access Employee
Brown
Black, Brown: read, write
Black’s Employee
Black
CSCE Farkas

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

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

25. Access Control RBAC

26. Reading assignments Required for access control classes:
Ravi Sandhu, Edward Coyne, Hal Feinstein and Charles Youman, Role-Based Access Control Models, IEEE Computer, Volume 29, Number 2, February
CSCE Farkas
Lecture 16

27. 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 Farkas
Lecture 16

28. Motivation Express organizational policies
Separation of duties
Delegation of authority
Flexible: easy to modify to meet new security requirements
Supports
Least-privilege
Data abstraction
CSCE Farkas
Lecture 16

29. CANNOT ENFORCE THESE PRINCIPLES
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 Farkas
Lecture 16

30. 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 Farkas
Lecture 16

31. RBAC RBAC3 consolidated model RBAC1 RBAC2 role hierarchy constraints
RBAC0 base model
CSCE Farkas
Lecture 16

32. RBAC0 U Users User assignment Permission assignment R Roles P . . S
Permissions . . S
Sessions
CSCE Farkas
Lecture 16

33. RBAC0 User: human beings Role: job function (title)
Permission: approval of a mode of access
(object, access mode)
Always positive
Abstract representation
Can apply to single object or to many
CSCE Farkas
Lecture 16

34. RBAC0 UA: user-role assignments PA: role-permission assignment
Many-to-many
PA: role-permission assignment
Session: mapping of a single 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 Farkas
Lecture 16

35. RBAC0 Components Users, Roles, Permissions, Sessions
PA  P x R (many-to-many)
UA  U x R (many-to-many)
user: S  U, mapping each session si to a single user user(si)
roles: S  2R, mapping each session si to a set of roles roles(si)  {r | (user(si),r)  UA} and si has permissions  rroles(si) {p | (p,r)  PA}
CSCE Farkas
Lecture 16

36. RBAC0 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
CSCE Farkas
Lecture 16

37. RBAC1 Role Hierarchy . U Users R Roles P S Sessions User assignment
Permissions S
Sessions
User
assignment
Permission
CSCE Farkas
Lecture 16

38. RBAC1 Structuring roles
Inheritance of permission from junior role (bottom) to senior role (top)
Partial order
Reflexive
Transitive
Anti-symmetric
CSCE Farkas
Lecture 16

39. RBAC1 Components
Same as RBAC0: Users, Roles, Permissions, Sessions, PA  P x R, UA  U x R, user: S  U, mapping each session si to a single user user(si)
RH  R x R, partial order ( dominance)
roles: S  2R, mapping each session si to a set of roles roles(si)  {r | (r’  r) [(user(si),r’)  UA]} and si has permissions  rroles(si) {p | (r”  r) [(p,r”)  PA]}
CSCE Farkas
Lecture 16

40. RBAC1 Role Hierarchy Specialist Primary-care Physician Physician
Inheritance of
privileges
Physician
Health-care provider
CSCE Farkas
Lecture 16

41. RBAC2 U Users User assignment Permission assignment R Roles P
Permissions
Constraints . . S
Sessions
CSCE Farkas
Lecture 16

42. RBAC2 – Constraints Enforces high-level organizational policies
Management of decentralized security
Constraints define “acceptable” and “not acceptable” accesses
CSCE Farkas
Lecture 16

43. RBAC2 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 Farkas
Lecture 16

44. RBAC2 Constraints can apply to sessions, user and roles functions
CSCE Farkas
Lecture 16

45. RBAC3 Role Hierarchy . U Users R Roles P S Sessions User assignment
Permissions S
Sessions
User
assignment
Permission
Constraints
CSCE Farkas
Lecture 16

46. Next Class
Mandatory Access Control
CSCE Farkas