What is Access Control? Discretionary Access Control (DAC)

Slides:



Advertisements
Similar presentations
Trusted System Elements and Examples CS461/ECE422 Fall 2011.
Advertisements

Operating System Security
1 cs691 chow C. Edward Chow Confidentiality Policy CS691 – Chapter 5 of Matt Bishop.
Jan. 2014Dr. Yangjun Chen ACS Database security and authorization (Ch. 22, 3 rd ed. – Ch. 23, 4 th ed. – Ch. 24, 6 th )
CMSC 414 Computer (and Network) Security Lecture 13 Jonathan Katz.
Computer Security: Principles and Practice Chapter 10 – Trusted Computing and Multilevel Security.
Access Control Methodologies
Some slides were taken from Database Access Control Tutorial, Lars Olson, UIUC CS463, Computer Security.
Access Control Patterns Fatemeh Imani Mehr Amirkabir university of technology, Department of Computer Engineering & Information Technology.
Database Security - Farkas 1 Database Security and Privacy.
Access Control Intro, DAC and MAC System Security.
Security Fall 2009McFadyen ACS How do we protect the database from unauthorized access? Who can see employee salaries, student grades, … ? Who can.
CS-550 (M.Soneru): Protection and Security - 1 [SaS] 1 Protection and Security.
CMSC 414 Computer and Network Security Lecture 9 Jonathan Katz.
CMSC 414 Computer and Network Security Lecture 11 Jonathan Katz.
Chapter 8 Security Transparencies © Pearson Education Limited 1995, 2005.
Information Systems Security Security Architecture Domain #5.
View n A single table derived from other tables which can be a base table or previously defined views n Virtual table: doesn’t exist physically n Limitation.
Lecture 7 Access Control
Distributed Computer Security 8.2 Discretionary Access Control Models - Sai Phalgun Tatavarthy.
Dr. Kalpakis CMSC 621, Advanced Operating Systems. Fall 2003 URL: Security & Protection.
Lecture slides prepared for “Computer Security: Principles and Practice”, 2/e, by William Stallings and Lawrie Brown, Chapter 4 “Overview”.
CMSC 414 Computer and Network Security Lecture 19 Jonathan Katz.
CS-550 (M.Soneru): Protection and Security - 2 [SaS] 1 Protection and Security - 2.
Dr. Kalpakis CMSC 621, Advanced Operating Systems. Security & Protection.
CS426Fall 2010/Lecture 191 Computer Security CS 426 Lecture 19 Discretionary Access Control.
CH14 – Protection / Security. Basics Potential Violations – Unauthorized release, modification, DoS External vs Internal Security Policy vs Mechanism.
© G. Dhillon, IS Department Virginia Commonwealth University Principles of IS Security Formal Models.
3/16/2004Biba Model1 Biba Integrity Model Presented by: Nathan Balon Ishraq Thabet.
Switch off your Mobiles Phones or Change Profile to Silent Mode.
Controlling Files Richard Newman based on Smith “Elementary Information Security”
CSCE 548 Secure Software Development Weak Password-Based Systems Store and Protect Data Securely Information Leakage Failure to Handle Errors Correctly.
Session 2 - Security Models and Architecture. 2 Overview Basic concepts The Models –Bell-LaPadula (BLP) –Biba –Clark-Wilson –Chinese Wall Systems Evaluation.
Security Architecture and Design Chapter 4 Part 3 Pages 357 to 377.
CSCE 201 Introduction to Information Security Fall 2010 Access Control.
G53SEC 1 Access Control principals, objects and their operations.
Access Control. What is Access Control? The ability to allow only authorized users, programs or processes system or resource access The ability to disallow.
CE Operating Systems Lecture 21 Operating Systems Protection with examples from Linux & Windows.
G53SEC 1 Reference Monitors Enforcement of Access Control.
Database Security.
Access Control MAC. CSCE Farkas 2 Lecture 17 Reading assignments Required for access control classes:  Ravi Sandhu and P. Samarati, Access Control:
Access Controls Henry Parks SSAC 2012 Presentation Outline Purpose of Access Controls Access Control Models –Mandatory –Nondiscretionary/Discretionary.
Academic Year 2014 Spring Academic Year 2014 Spring.
COEN 350: Network Security Authorization. Fundamental Mechanisms: Access Matrix Subjects Objects (Subjects can be objects, too.) Access Rights Example:
CSCE 201 Introduction to Information Security Fall 2010 Access Control Models.
Trusted Operating Systems
Access Control: Policies and Mechanisms Vinod Ganapathy.
Privilege Management Chapter 22.
Computer Security: Principles and Practice
Introduction Database Security Overview. Readings This lecture: This lecture: –Textbook: Chapter 5.2 –Lecture materials from CSCE 522, Nov. 3, Lecture.
Access Control.
Protection & Security Greg Bilodeau CS 5204 October 13, 2009.
Security Overview. Security Objectives Confidentiality: prevent/detect/deter improper disclosure of information Integrity: prevent/detect/deter improper.
Lecture 14 Page 1 CS 111 Summer 2013 Security in Operating Systems: Basics CS 111 Operating Systems Peter Reiher.
Database Security. Introduction to Database Security Issues (1) Threats to databases Loss of integrity Loss of availability Loss of confidentiality To.
Database Security Database System Implementation CSE 507 Some slides adapted from Navathe et. Al.
Access Controls Mandatory Access Control by Sean Dalton December 5 th 2008.
PREPARED BY: MS. ANGELA R.ICO & MS. AILEEN E. QUITNO (MSE-COE) COURSE TITLE: OPERATING SYSTEM PROF. GISELA MAY A. ALBANO PREPARED BY: MS. ANGELA R.ICO.
22 feb What is Access Control? Access control is the heart of security Definitions: * The ability to allow only authorized users, programs or.
IST 210 Security. IST 210 Introduction to DB Security Secrecy: Users should not be able to see things they are not supposed to. E.g., A student can’t.
Chapter 5 : DataBase Security Lecture #1-Week 8 Dr.Khalid Dr. Mohannad Information Security CIT460 Information Security Dr.Khalid Dr. Mohannad 1.
Database System Implementation CSE 507
CSCE 522 Access Control.
Access Control Model SAM-5.
Access Control CSE 465 – Information Assurance Fall 2017 Adam Doupé
Computer Data Security & Privacy
OS Access Control Mauricio Sifontes.
Access Control.
Computer Security Access Control
Access Control What’s New?
Presentation transcript:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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