Access Control Models What is Access Control Discretionary

Access Control Models What is Access Control? Discretionary Access Control (DAC) Access Control Models CSCE 522 - Eastman/Farkas - Fall 2005

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

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

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

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

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 522 - Eastman/Farkas - Fall 2005 6

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

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

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

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

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

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

Access Control n Protection objects: system resources for which protection is desirable n Memory, file, directory, hardware resource, software resources, etc. n Subjects: active entities requesting accesses to resources n User, owner, program, etc. n Access mode: type of access n Read, write, execute Access Control Models CSCE 522 - Eastman/Farkas - Fall 2005 13

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

Access Control n Access control: ensures that all direct accesses to object are authorized n Protects against accidental and malicious threats by regulating the reading, writing and execution of data and programs n Need: n Proper user identification and authentication n Information specifying the access rights is protected from modification Access Control Models CSCE 522 - Eastman/Farkas - Fall 2005 15

Access Control n Access control components: Access control policy: specifies the authorized accesses of a system n Access control mechanism: implements and enforces the policy n Separation of components allows us to: n Define access requirements independently from implementation n Compare different policies n Implement mechanisms that can enforce a wide range of policies n Access Control Models CSCE 522 - Eastman/Farkas - Fall 2005 16

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

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 n Ownership based: owner of data may grant access to other to his/her data (possibly with grant option) n Cooperative authorization: predefined groups of users or predefined number of users may access data n n Access Control Models CSCE 522 - Eastman/Farkas - Fall 2005 18

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

Discretionary Access Control n Access control is based on n User’s identity and n Access control rules n Most common administration: owner based n Users can protect what they own n Owner may grant access to others n Owner may define the type of access given to others Access Control Models CSCE 522 - Eastman/Farkas - Fall 2005 20

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

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

Implementation Access Control List (column) (ACL) File 1 Joe: Read Joe: Write Joe: Own Capability List (row) File 2 Joe: Read Sam: Write Sam: Own Joe: File 1/Read, File 1/Write, File 1/Own, File 2/Read Sam: File 2/Read, File 2/Write, File 2/Own Access Control Triples Access Control Models Subject Access Joe Read Joe Write Joe Own Joe Read Sam Write CSCE 522 - Eastman/Farkas - Fall 2005 Sam Own Object File 1 File 2 23

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

Access Control Conditions n Data-dependent conditions: access constraints based on the value of the accessed data n Time-dependent: access constraints based on the time of the data access n Context-dependent: access constraints based on combinations on data which can be accessed n History-dependent: access constraints based on previously accessed data Access Control Models CSCE 522 - Eastman/Farkas - Fall 2005 25

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

Security Through Views n 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 522 - Eastman/Farkas - Fall 2005 27

Security Through Views Student relation NAME COURSE GRADE SEMESTER White CSCE 122 C+ Fall 2000 Black CSCE 313 A Fall 2000 Brown CSCE 580 A Spring 2000 Green CSCE 850 B+ Fall 2000 Blue CSCE 122 B Fall 2000 Access Control Models CSCE 522 - Eastman/Farkas - Fall 2005 28

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 A Green CSCE 850 B+ Access Control Models CSCE 522 - Eastman/Farkas - Fall 2005 29

Security Through Views CREATE VIEW Fall-Student AS SELECT NAME, COURSE FROM Student WHERE SEMESTER=“Fall 2000” Fall-Student Access Control Models NAME COURSE White CSCE 122 Black CSCE 313 Green CSCE 850 Blue CSCE 122 CSCE 522 - Eastman/Farkas - Fall 2005 30

Stored Procedures n Assign rights to execute compiled programs n 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 522 - Eastman/Farkas - Fall 2005 31

Grant and Revoke GRANT <privilege> ON <relation> To <user> [WITH GRANT OPTION] n GRANT SELECT * ON Student TO Matthews n GRANT SELECT *, UPDATE(GRADE) ON Student TO FARKAS n GRANT SELECT(NAME) ON Student TO Brown GRANT command applies to base relations as well as views Access Control Models CSCE 522 - Eastman/Farkas - Fall 2005 32

Grant and Revoke REVOKE <privileges> [ON <relation>] FROM <user> n REVOKE SELECT* ON Student FROM Blue n REVOKE UPDATE ON Student FROM Black n REVOKE SELECT(NAME) ON Student FROM Brown Access Control Models CSCE 522 - Eastman/Farkas - Fall 2005 33

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

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

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

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

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

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

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

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

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

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

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 522 - Eastman/Farkas - Fall 2005 44

Mandatory Access Control § If access control rules are satisfied, access is permitted q e. g. , Joe wants to read grades. q label(Joe)=(confidential, {student-info}) q label(grades)=(confidential, {student-info}) q Joe is permitted to read grades § Granularity of access rights! Access Control Models CSCE 522 - Eastman/Farkas - Fall 2005 45

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

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 522 - Eastman/Farkas - Fall 2005 47

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

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

BLP Reference Monitor n All accesses are controlled by the reference monitor n Cannot be bypassed n Access is allowed iff the resulting system state satisfies all security properties n Trusted subjects: subjects trusted not to compromise security Access Control Models CSCE 522 - Eastman/Farkas - Fall 2005 50

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 n No read up n Applies to all subjects Access Control Models CSCE 522 - Eastman/Farkas - Fall 2005 51

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 n. No write down n. Applies only Access Control Models to un-trusted subjects CSCE 522 - Eastman/Farkas - Fall 2005 52

Trojan Horses and BLP Brown: read, write Word Processor Use shared program Brown Secret Reference Monitor Employee Secret Read Employee Black, Brown: read, write Black’s Employee TH Black Public Insert Trojan Horse Into shared program Access Control Models Copy Employee To Black’s Employee CSCE 522 - Eastman/Farkas - Fall 2005 Public Secret Public 53

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

Tranquility n Read and write accesses mediated based on the security labels of objects and subjects n Read and write accesses are not atomic, i. e. , sequences of operations that may or may not be interrupted n 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 522 - Eastman/Farkas - Fall 2005 55

Strong Tranquility n Tranquility: changing security labels n Strong tranquility: security labels of subjects and objects never change during an operation n Advantage: system state always satisfies security requirements n Disadvantage: not flexible Access Control Models CSCE 522 - Eastman/Farkas - Fall 2005 56

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 522 - Eastman/Farkas - Fall 2005 57

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

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

Strict Integrity Policy n 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) n 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) n Invocation property: a subject s 1 can invoke a subject s 2 only if the integrity label of s 1 dominates the integrity label of s 2 Access Control Models CSCE 522 - Eastman/Farkas - Fall 2005 60