1. What is Access Control? Discretionary Access Control (DAC)
Access Control Models
What is Access Control?
Discretionary Access Control (DAC)

2. Operating Systems Manage Resources
Resources managed
Memory, CPU, programs, data, networks, etc.
Evaluation criteria
Efficiency
Utilization
Protection!!!
Access Control Models
CSCE Eastman/Farkas - Fall 2005

3. CSCE 522 - Eastman/Farkas - Fall 2005
Separation vs. Sharing
Separation of resources
Keep different users’ resources separate
Physical, temporal, logical, cryptographic
Sharing of resources
Users/processes may need/want to share files, programs, data, etc.
Access control
Inherent conflict between separation and sharing
Access Control Models
CSCE Eastman/Farkas - Fall 2005

4. Memory and Address Protection
Fence/fence register
Relocation
Base/bounds register
Tagged architecture
Segmentation
Paging
Access Control Models
CSCE Eastman/Farkas - Fall 2005

5. CSCE 522 - Eastman/Farkas - Fall 2005
File Protection
All or nothing protection (private, public)
Group protection (private, group, public)
Defining groups
Maintaining groups
Handling overlapping groups
Password protection
Access Control Models
CSCE Eastman/Farkas - Fall 2005

6. CSCE 522 - Eastman/Farkas - Fall 2005
Access Control
A trusted operating system needs to provide controlled access to resources so that only appropriate users can access resources
What are the resources?
Who are the users?
What is an appropriate access?
Need access control policies and models
Access Control Models
CSCE Eastman/Farkas - Fall 2005

7. CSCE 522 - Eastman/Farkas - Fall 2005
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
Access Control Models
CSCE Eastman/Farkas - Fall 2005

8. Access Control Example
Access Control Policy for son Edward
Allowed access:
House
Disallowed access:
Automobile
Access Control Models
CSCE Eastman/Farkas - Fall 2005

9. Access Control Example
Access Control Policy for son Edward
Allowed access:
House
Disallowed access:
Automobile
Access Control Models
CSCE Eastman/Farkas - Fall 2005

10. CSCE 522 - Eastman/Farkas - Fall 2005
Access Control Example 
Access Control policy
Allowed access:
House:
Disallowed access:
Automobile
Problem!
Unauthorized access
Access Control Models
CSCE Eastman/Farkas - Fall 2005

11. CSCE 522 - Eastman/Farkas - Fall 2005
Access Control Example
Access Control Policy for son Edward
Allowed access:
House
Kitchen
Disallowed access:
Automobile
Car key
Access Control Models
CSCE Eastman/Farkas - Fall 2005

12. CSCE 522 - Eastman/Farkas - Fall 2005
Access Control Example 
Correct Access Control Policy for son Edward
Allowed access:
House
Kitchen
Disallowed access:
Automobile
Car key
Access Control Models
CSCE Eastman/Farkas - Fall 2005

13. CSCE 522 - Eastman/Farkas - Fall 2005
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
Access Control Models
CSCE Eastman/Farkas - Fall 2005

14. Access Control Requirements
Cannot be bypassed
Enforce least-privilege and need-to-know restrictions
Enforce organizational policy
Access Control Models
CSCE Eastman/Farkas - Fall 2005

15. CSCE 522 - Eastman/Farkas - Fall 2005
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 from modification
Access Control Models
CSCE Eastman/Farkas - Fall 2005

16. CSCE 522 - Eastman/Farkas - Fall 2005
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 us to:
Define access requirements independently from implementation
Compare different policies
Implement mechanisms that can enforce a wide range of policies
Access Control Models
CSCE Eastman/Farkas - Fall 2005

17. CSCE 522 - Eastman/Farkas - Fall 2005
Closed v.s. Open Systems
Closed system
Open System
(minimum privilege)
(maximum privilege)
Access
request
Access
request
Allowed
accesses
Disallowed
accesses
Rule exists?
Rule exists?
yes no no
yes
Access
permitted
Access
denied
Access
permitted
Access
denied
Access Control Models
CSCE Eastman/Farkas - Fall 2005

18. CSCE 522 - Eastman/Farkas - Fall 2005
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
Access Control Models
CSCE Eastman/Farkas - Fall 2005

19. CSCE 522 - Eastman/Farkas - Fall 2005
Access Control Models
All accesses
Discretionary AC
Mandatory AC
Role-Based AC
Access Control Models
CSCE Eastman/Farkas - Fall 2005

20. 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
Access Control Models
CSCE Eastman/Farkas - Fall 2005

21. CSCE 522 - Eastman/Farkas - Fall 2005
Access Matrix Model
OBJECTS AND SUBJECTS
File 1
File 2 S U B J E C T
Read
Write
Own
Joe
Sam
Access Control Models
CSCE Eastman/Farkas - Fall 2005

22. CSCE 522 - Eastman/Farkas - Fall 2005
Discretionary Security Property
Every current access must be in the access matrix
Access Control Models
CSCE Eastman/Farkas - Fall 2005

23. CSCE 522 - Eastman/Farkas - Fall 2005
Implementation
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
Access Control Models
CSCE Eastman/Farkas - Fall 2005

24. CSCE 522 - Eastman/Farkas - Fall 2005
ACL v.s. Capabilities
ACL:
Per object based
Good for file systems
Capabilities:
Per subject based
Good for environment with dynamic, short-lived subjects
Access Control Models
CSCE Eastman/Farkas - Fall 2005

25. 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
Access Control Models
CSCE Eastman/Farkas - Fall 2005

26. Access Control Mechanisms
Security through Views
Stored Procedures
Grant and Revoke
Query modification
Will revisit with databases
Access Control Models
CSCE Eastman/Farkas - Fall 2005

27. CSCE 522 - Eastman/Farkas - Fall 2005
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.
Access Control Models
CSCE Eastman/Farkas - Fall 2005

28. 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
Access Control Models
CSCE Eastman/Farkas - Fall 2005

29. 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+
Access Control Models
CSCE Eastman/Farkas - Fall 2005

30. 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
Access Control Models
CSCE Eastman/Farkas - Fall 2005

31. CSCE 522 - Eastman/Farkas - Fall 2005
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.
Access Control Models
CSCE Eastman/Farkas - Fall 2005

32. CSCE 522 - Eastman/Farkas - Fall 2005
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
Access Control Models
CSCE Eastman/Farkas - Fall 2005

33. CSCE 522 - Eastman/Farkas - Fall 2005
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
Access Control Models
CSCE Eastman/Farkas - Fall 2005

34. CSCE 522 - Eastman/Farkas - Fall 2005
Non-cascading Revoke A B C D E F
A revokes D’s privileges E B A F C
Access Control Models
CSCE Eastman/Farkas - Fall 2005

35. CSCE 522 - Eastman/Farkas - Fall 2005
Cascading Revoke A B C D E F
A revokes D’s privileges B A C
Access Control Models
CSCE Eastman/Farkas - Fall 2005

36. Positive and Negative AuthorizationB C E D + -
Problem:
Contradictory authorizations
GRANT <privilege> ON X TO <user>
DENY <privilege> ON X TO <user>
Access Control Models
CSCE Eastman/Farkas - Fall 2005

37. Negative AuthorizationB C E D + - -
Positive authorization granted
By A to D becomes blocked but
NOT deleted.
Access Control Models
CSCE Eastman/Farkas - Fall 2005

38. Negative AuthorizationB C E D + - - + F
What should happen with the privilege given by D
To F? (Blocked but not deleted)
Access Control Models
CSCE Eastman/Farkas - Fall 2005

39. CSCE 522 - Eastman/Farkas - Fall 2005
Query Modification
GRANT SELECT(NAME) ON Student TO Blue WHERE COURSE=“CSCE 590”
Blue’s query:
SELECT *
FROM Student
Modified query:
SELECT NAME
WHERE COURSE=“CSCE 580”
Access Control Models
CSCE Eastman/Farkas - Fall 2005

40. CSCE 522 - Eastman/Farkas - Fall 2005
Current Research
Make cascading optional
Permit negative authorization
Flexible policies for resolving conflicts
Extend to groups and views
Access Control Models
CSCE Eastman/Farkas - Fall 2005

41. CSCE 522 - Eastman/Farkas - Fall 2005
DAC and Trojan Horses
Brown: read, write
Employee
Read Employee
REJECTED!
Black is not allowed
To access Employee
Brown
Black, Brown: read, write
Black’s Employee
Black
Access Control Models
CSCE Eastman/Farkas - Fall 2005

42. CSCE 522 - Eastman/Farkas - Fall 2005
DAC and Trojan Horses
Brown: read, write
Employee
Word
Processor
Reads
Employee
Uses shared program
Brown
Black, Brown: read, write
Black’s Employee TH
Inserts Trojan Horse
Into shared program
Copies
Employee
To Black’s
Black
Access Control Models
CSCE Eastman/Farkas - Fall 2005

43. CSCE 522 - Eastman/Farkas - Fall 2005
DAC Overview
Advantages:
Intuitive
Easy to implement
Disadvantages:
Inherent vulnerability (TH example)
Maintenance of ACL or Capability lists
Maintenance of Grant/Revoke
Limited power of negative authorization
Access Control Models
CSCE Eastman/Farkas - Fall 2005

44. CSCE 522 - Eastman/Farkas - Fall 2005
Mandatory Access Control (MAC)
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)
Access Control Models
CSCE Eastman/Farkas - Fall 2005

45. CSCE 522 - Eastman/Farkas - Fall 2005
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!
Access Control Models
CSCE Eastman/Farkas - Fall 2005

46. CSCE 522 - Eastman/Farkas - Fall 2005
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,{ })
Access Control Models
CSCE Eastman/Farkas - Fall 2005

47. CSCE 522 - Eastman/Farkas - Fall 2005
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})
Access Control Models
CSCE Eastman/Farkas - Fall 2005

48. CSCE 522 - Eastman/Farkas - Fall 2005
Bell- LaPadula (BLP) Model
Confidentiality protection
Lattice-based access control
Subjects
Objects
Security labels
Supports decentralized administration
Access Control Models
CSCE Eastman/Farkas - Fall 2005

49. CSCE 522 - Eastman/Farkas - Fall 2005
Bell- LaPadula (BLP) Model
Allowed BLP access types
Execute
Read
Write
Append (aka blind write)
Access Control Models
CSCE Eastman/Farkas - Fall 2005

50. CSCE 522 - Eastman/Farkas - Fall 2005
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
Access Control Models
CSCE Eastman/Farkas - Fall 2005

51. CSCE 522 - Eastman/Farkas - Fall 2005
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
Access Control Models
CSCE Eastman/Farkas - Fall 2005

52. CSCE 522 - Eastman/Farkas - Fall 2005
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
Access Control Models
CSCE Eastman/Farkas - Fall 2005

53. CSCE 522 - Eastman/Farkas - Fall 2005
Trojan Horses and BLP
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
Access Control Models
CSCE Eastman/Farkas - Fall 2005

54. CSCE 522 - Eastman/Farkas - Fall 2005
Blind Writes
Improper modification of data
Most implementations disallow blind writes
Access Control Models
CSCE Eastman/Farkas - Fall 2005

55. CSCE 522 - Eastman/Farkas - Fall 2005
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
Access Control Models
CSCE Eastman/Farkas - Fall 2005

56. CSCE 522 - Eastman/Farkas - Fall 2005
Strong 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
Access Control Models
CSCE Eastman/Farkas - Fall 2005

57. CSCE 522 - Eastman/Farkas - Fall 2005
Weak 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.
Access Control Models
CSCE Eastman/Farkas - Fall 2005

58. CSCE 522 - Eastman/Farkas - Fall 2005
Biba Model
Integrity protection
Lattice-based access control
Subjects
Objects
Integrity labels
Access Control List
Access Control Models
CSCE Eastman/Farkas - Fall 2005

59. CSCE 522 - Eastman/Farkas - Fall 2005
Integrity Labels
Hierarchical integrity levels: e.g.,
Crucial > Very important > Important
Non-hierarchical categories: e.g.,
{medical, personal, administrative}
Access Control Models
CSCE Eastman/Farkas - Fall 2005

60. CSCE 522 - Eastman/Farkas - Fall 2005
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
Access Control Models
CSCE Eastman/Farkas - Fall 2005