1 / 20

Access Control MAC

Access Control MAC. Reading assignments. Recommended: Ravi Sandhu , Lattice-Based Access Control Models, IEEE Computer, Volume 26, Number 11 (Cover Article), November 1993 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.54.8395. Mandatory Access Control.

duncanh
Télécharger la présentation

Access Control MAC

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Access ControlMAC

  2. Reading assignments Recommended: • Ravi Sandhu, Lattice-Based Access Control Models, IEEE Computer, Volume 26, Number 11 (Cover Article), November 1993 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.54.8395 CSCE 522 - Farkas

  3. 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 522 - Farkas

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

  5. 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 522 - Farkas

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

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

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

  9. BLP Axioms 1. Simple-security property: a subject s is allowed to read an object oonly if the security label of s dominates the security label of o • No read up • Applies to all subjects CSCE 522 - Farkas

  10. BLP Axioms 2. *-property: a subject s is allowed to write an object oonly if the security label of o dominates the security label of s • No write down • Applies to un-trusted subjects only CSCE 522 - Farkas

  11. Blind Writes • Improper modification of data • Most implementations disallow blind writes CSCE 522 - Farkas

  12. 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 522 - Farkas

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

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

  15. Discretionary Security Property • Every current access must be in the access matrix CSCE 522 - Farkas

  16. Trojan Horse 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 Employee Public Insert Trojan Horse Into shared program Black Secret  Public Public CSCE 522 - Farkas

  17. Biba Model – Integrity Protection • Integrity protection • Lattice-based access control • Subjects • Objects • Integrity labels • Access Control List CSCE 522 - Farkas

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

  19. 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 522 - Farkas

  20. Next Class: Database Security CSCE 522 - Farkas

More Related