1. Access Control

2. Reading
Today: Role-Based Access Control Models (David F. Ferraiolo, Ravi Sandhu, Serban Gavrila, D. Richard Kuhn and Ramaswamy Chandramouli, Proposed NIST Standard for Role-Based Access Control, ACM Transactions on Information and Systems Security (TISSEC), Volume 4, Number 3, August 2001
 Next Class: P. Roberts, Building And Maintaining Database Access Control Permissions,
CSCE Farkas

3. Security Controls Access Control Inference Control Flow control
CSCE Farkas

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

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

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

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

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

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

10. Access Control Models All accesses Discretionary AC Mandatory AC
Role-Based AC
CSCE Farkas

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

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

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

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

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

16. Access Control Mechanisms
Security through Views
Stored Procedures
Grant and Revoke
Query modification
CSCE Farkas

17. Security Through Views
Assign rights to access predefined views
CREATE VIEW Outstanding-Student
AS SELECT NAME, COURSE, GRADE
FROM Student
WHERE GRADE > B
Problem:
Difficult to maintain updates.
CSCE Farkas

18. Security Through Views
Student relation
NAME
COURSE
GRADE
SEMESTER
White
CSCE 122 C+
Fall 2000
Black
CSCE 313 A
Brown
CSCE 580
Spring 2000
Green
CSCE 850 B+
Blue B
CSCE Farkas

19. Security Through Views
CREATE VIEW Outstanding-Student
AS SELECT NAME, COURSE, GRADE
FROM Student
WHERE GRADE > B
Outstanding-Student
NAME
COURSE
GRADE
Black
CSCE 313 A
Brown
CSCE 580
Green
CSCE 850 B+
CSCE Farkas

20. Security Through Views
CREATE VIEW Fall-Student
AS SELECT NAME, COURSE
FROM Student
WHERE SEMESTER=“Fall 2000”
NAME
COURSE
White
CSCE 122
Black
CSCE 313
Green
CSCE 850
Blue
Fall-Student
CSCE Farkas

21. Stored Procedures Assign rights to execute compiled programs
GRANT RUN ON <program> TO <user>
Problem:
Programs may access resources for which the user who runs the program does not have permission.
CSCE Farkas

22. Grant and Revoke GRANT <privilege> ON <relation>
To <user>
[WITH GRANT OPTION]
GRANT SELECT * ON Student TO Matthews
GRANT SELECT *, UPDATE(GRADE) ON Student TO FARKAS
GRANT SELECT(NAME) ON Student TO Brown
GRANT command applies to base relations as well as views
CSCE Farkas

23. Grant and Revoke REVOKE <privileges> [ON <relation>]
FROM <user>
REVOKE SELECT* ON Student FROM Blue
REVOKE UPDATE ON Student FROM Black
REVOKE SELECT(NAME) ON Student FROM Brown
CSCE Farkas

24. Non-cascading Revoke A B C D E F A revokes D’s privileges E B A F C
CSCE Farkas

25. Cascading Revoke A B C D E F A revokes D’s privileges B A C
CSCE Farkas

26. Positive and Negative AuthorizationB C E D + -
Problem:
Contradictory authorizations
GRANT <privilege> ON X TO <user>
DENY <privilege> ON X TO <user>
CSCE Farkas

27. Negative AuthorizationB C E D + - -
Positive authorization granted
By A to D becomes blocked but
NOT deleted.
CSCE Farkas

28. Negative AuthorizationB C E D + - - + F
What should happen with the privilege given by D
To F? (Blocked but not deleted)
CSCE Farkas

29. Query Modification
GRANT SELECT(NAME) ON Student TO Blue WHERE COURSE=“CSCE 580”
Blue’s query:
SELECT *
FROM Student
Modified query:
SELECT NAME
WHERE COURSE=“CSCE 580”
CSCE Farkas

30. Current Research Make cascading optional Permit negative authorization
Flexible policies for resolving conflicts
Extend to groups and views
CSCE Farkas

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

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

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

34. 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 Farkas

35. Mandatory Access Control
If access control rules are satisfied, access is permitted
e.g., Joe wants to read grades.
label(Joe)=(confidential,{student-info})
label(grades)=(confidential,{student-info})
Joe is permitted to read grades
Granularity of access rights!
CSCE Farkas

36. 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,{student-info,dept-info})
(confidential,{student-info})
(confidential,{dept-info})
(confidential,{ })
(public,{student-info,dept-info})
(public,{student-info})
(public,{,dept-info})
(public,{ })
CSCE Farkas

37. 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 Farkas

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

39. 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 Farkas

40. 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 Farkas

41. BLP Axioms 2.
*-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
CSCE Farkas

42. Blind Writes Improper modification of data
Most implementations disallow blind writes
CSCE Farkas

43. Tranquility
Read and write accesses mediated based on the security labels of objects and subjects
Read and write accesses are not atomic, i.e., sequences of operations that may or may not be interrupted
Example: secret subject requests a read to a secret object. While the request is being processed, the subjects lowers its level to unclassified => unclassified subject gained read access to secret object
CSCE Farkas

44. Tranquility Tranquility: changing security labels
Strong tranquility: security labels of subjects and objects never change during an operation
Advantage: system state always satisfies security requirements
Disadvantage: not flexible
CSCE Farkas

45. Tranquility
Weak tranquility: security labels of subjects and objects never change such a way as to violate the security policy
High watermark on subject: during read a subject may upgrade its security clearance
High watermark on objects: during write an object’s security classification may be upgraded.
CSCE Farkas

46. Discretionary Security Property
Every current access must be in the access matrix
CSCE Farkas

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

48. Biba Model – Integrity Protection
Lattice-based access control
Subjects
Objects
Integrity labels
Access Control List
CSCE Farkas

49. Integrity Labels Hierarchical integrity levels: e.g.,
Crucial > Very important > Important
Non-hierarchical categories: e.g.,
{medical, personal, administrative}
CSCE Farkas

50. Strict Integrity Policy
Integrity *-property: a subject s can modify an object o only if the integrity level of the subject dominates the integrity level of the object (no write up)
Simple integrity property: a subject s can observe an object o only if the integrity label of s is dominated by the integrity label of o (no read down)
Invocation property: a subject s1 can invoke a subject s2 only if the integrity label of s1 dominates the integrity label of s2
CSCE Farkas

51. Role-Based Access Control
CSCE Farkas

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

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

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

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

56. RBAC RBAC3 consolidated model RBAC1 RBAC2 role hierarchy constraints
RBAC0 base model
CSCE Farkas

57. RBAC0 U Users User assignment Permission assignment R Roles P . . S
Permissions . . S
Sessions
CSCE Farkas

58. 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 Farkas

59. RBAC0 UA: user assignments PA: Permission assignment
Many-to-many
PA: Permission assignment
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 Farkas

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

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

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

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

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

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

66. RBAC1 Limit scope of inheritance Private Roles Project Project
Supervisor
Project
Supervisor
Test
Engineer’
Programmer’
Test
Engineer
Programmer
Test
Engineer
Programmer
Project
Member
Project
Member
CSCE Farkas

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

68. RBAC2 – Components
Same as RBAC0 + Constraints
CSCE Farkas

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

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

71. RBAC2 Constraints can apply to sessions, user and roles functions
CSCE Farkas

72. RBAC3 . U Users R Roles P S Sessions User assignment Permission
Permissions S
Sessions
User
assignment
Permission
Constraints
CSCE Farkas

73. Next class
The inference problem
CSCE Farkas