1 / 44

CSCE 522 Access Control

CSCE 522 Access Control. Reading. Reading for this lecture: Required: Pfleeger : Ch. 2.2 Recommended:

rebap
Download Presentation

CSCE 522 Access Control

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. CSCE 522Access Control

  2. Reading • Reading for this lecture: Required: • Pfleeger: Ch. 2.2 • Recommended: • S. De Capitani di Vimercati, P. Samarati, S. Jajodia: Policies, Models, and Languages for Access Control, in Databases in Networked Information Systems, Volume 3433 of the series Lecture Notes in Computer Science pp 225-237, http://spdp.di.unimi.it/papers/2005-DNIS.pdf CSCE 522 - Farkas

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

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

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

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

  7. System Architecture and Policy • Simple monolithic system • Distributed homogeneous system under centralized control • Distributed autonomous systems homogeneous domain • Distributed heterogeneous system Complexity Of Policy CSCE 522 - Farkas

  8. Closed v.s. Open Systems Closed system Open System (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 522 - Farkas

  9. Negative Authorization • Traditional systems: Mutual exclusion • New systems: combined use of positive and negative authorizations • Support exceptions • Problems: How to deal with • Incompleteness – Default policy • Inconsistencies – Conflict resolution CSCE 522 - Farkas

  10. Conflict Resolution • Denial takes precedence • Most specific takes precedence • Most specific along a path takes precedence • Priority-based • Positional • Grantor and time-dependent • Single strategy vs. combination of strategies CSCE 522 - Farkas

  11. Policy Specification Language • Express policy concepts • Required properties of policy languages: • Support access control, delegation, and obligation • Provide structuring constructs to handle large systems • Support composite policies • Must be able to analyze policies for conflicts and inconsistencies • Extensible • Comprehensible and easy to use CSCE 522 - Farkas

  12. Policy Development • Policy maker: • Start with high-level policies • Refine high-level policies to low-level policy specification • Determine resources required to satisfy the policy • Translate high-level policies into enforceable versions • Support analysis that verifies that lower level policies actually meet the needs of higher level ones. CSCE 824 - Farkas

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

  14. Access Control Models All accesses Discretionary AC DAC Mandatory AC Role-Based AC RBAC CSCE 522 - Farkas

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

  16. Access Matrix Model OBJECTS AND SUBJECTS File 1 File 2 S U B J E C T S Joe Sam CSCE 522 - Farkas

  17. 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 CSCE 522 - Farkas

  18. ACL vs. Capabilities • ACL: • Per object based • Good for file systems • Capabilities: • Per subject based • Good for environment with dynamic, short-lived subjects CSCE 522 - Farkas

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

  20. Read Employee REJECTED! Black is not allowed To access Employee DAC and Trojan Horse Brown: read, write Employee Brown Black, Brown: read, write Black’s Employee Black CSCE 522 - Farkas

  21. Reads Employee Copies Employee To Black’s Employee TH Inserts Trojan Horse Into shared program DAC and Trojan Horse Brown: read, write Employee Word Processor Uses shared program Brown Black, Brown: read, write Black’s Employee Black CSCE 522 - Farkas

  22. DAC Overview • Advantages: • Intuitive • Easy to implement • Disadvantages: • Inherent vulnerability (look TH example) • Maintenance of ACL or Capability lists • Maintenance of Grant/Revoke • Limited power of negative authorization CSCE 522 - Farkas

  23. Access ControlRBAC

  24. Reading assignments • Required for access control classes: • Ravi Sandhu, Edward Coyne, Hal Feinstein and Charles Youman, Role-Based Access Control Models, IEEE Computer, Volume 29, Number 2, February 1996 http://csrc.nist.gov/rbac/sandhu96.pdf CSCE 522 - Farkas

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

  26. Motivation • Express organizational policies • Separation of duties • Delegation of authority • Flexible: easy to modify to meet new security requirements • Supports • Least-privilege • Separation of duties • Data abstraction CSCE 522 - Farkas

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

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

  29. RBAC RBAC3 consolidated model RBAC1 role hierarchy RBAC2 constraints RBAC0 base model CSCE 522 - Farkas

  30. RBAC0 U Users User assignment Permission assignment R Roles P Permissions . . . S Sessions CSCE 522 - Farkas

  31. RBAC0 • User: human beings • Role: job function (title) • Permission: approval of a mode of access • (object, access mode) • Always positive • Abstract representation • Can apply to single object or to many CSCE 522 - Farkas

  32. RBAC0 • UA: user-role assignments • Many-to-many • PA: role-permission assignment • Many-to-many • Session: mapping of a single 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 522 - Farkas

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

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

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

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

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

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

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

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

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

  42. RBAC2 • Constraints can apply to sessions, user and roles functions CSCE 522 - Farkas

  43. User assignment Permission assignment U Users R Roles P Permissions . . . S Sessions Constraints RBAC3 Role Hierarchy CSCE 522 - Farkas

  44. Next Class • Mandatory Access Control CSCE 522 - Farkas

More Related