1 / 66

Lecture 7 Access Control

Lecture 7 Access Control. modified from slides of Lawrie Brown. Access Control. ITU-T Recommendation X.800 definition: “The prevention of unauthorized use of a resource, including the prevention of use of a resource in an unauthorized manner.” RFC 2828 defines computer security as :

paul
Download Presentation

Lecture 7 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. Lecture 7Access Control modified from slides of Lawrie Brown

  2. Access Control • ITU-T Recommendation X.800 definition: • “The prevention of unauthorized use of a resource, including the prevention of use of a resource in an unauthorized manner.” • RFC 2828 defines computer security as: • “Measures that implement and assure security services in a computer system, particularly those that assure access control service”.

  3. Access Control Principles Granting of a right or permission to an entity to access a system resource. Verification that the credentials of a user or an entity are valid. An independent review and examination of system records and activities

  4. Access Control Policies • dictates • what types of access are permitted, • under what circumstances, • by whom. based on comparing security labels with clearances based on the identity of the requestor and on access rules Attribute-based access control based on attributes of the user, the resource to be accessed, and current environmental conditions based on the roles and their accesses

  5. Access Control Requirements • reliable input • support for fine and coarse specifications • least privilege • separation of duty • open and closed policies • policy combinations and conflict resolution • administrative policies • dual control

  6. Access Control Basic Elements • subject entity capable of accessing objects • concept equates with that of process • typically held accountable for the actions they initiate • often have three classes: owner, group, world • object resource to which access is controlled • entity used to contain and/or receive information • protection depends on the environment in which access control operates • access right: the way in which a subject may access an object • e.g. read, write, execute, delete, create, search

  7. Discretionary Access Control • scheme in which an entity may enable another entity to access some resource • often provided using an access matrix • one dimension consists of identified subjects that may attempt data access to the resources • the other dimension lists the objects that may be accessed • each entry in the matrix indicates the access rights of a particular subject for a particular object

  8. Access Matrix

  9. Example of Access Control Structures

  10. Authorization Table

  11. Extended Access Control Matrix

  12. Access Control Function

  13. Access Control System Commands

  14. Protection Domains • set of objects together with access rights to those objects • more flexibility when associating capabilities with protection domains • in terms of the access matrix, a row defines a protection domain • user can spawn processes with a subset of the access rights of the user

  15. Protection Domains • association between a process and a domain can be static or dynamic • in user mode certain areas of memory are protected from use and certain instructions may not be executed • in kernel mode privileged instructions may be executed and protected areas of memory may be accessed

  16. UNIX File Access Control • UNIX files are administered using inodes (index nodes) • control structures with key information needed for a particular file • several file names may be associated with a single inode • an active inode is associated with exactly one file • file attributes, permissions and control information are sorted in the inode • on the disk there is an inode table, or inode list, that contains the inodes of all the files in the file system • when a file is opened its inode is brought into main memory and stored in a memory resident inode table • directories are structured in a hierarchical tree • may contain files and/or other directories • contains file names plus pointers to associated inodes

  17. unique user identification number (user ID) member of a primary group identified by a group ID belongs to a specific group 12 protection bits specify read, write, and execute permission for owner of file, members of group, and all other users owner ID, group ID, and protection bits are part of file’s inode UNIX File Access Control

  18. Traditional UNIX File Access Control • “set user ID”(SetUID) • “set group ID”(SetGID) • system temporarily uses rights of the file owner / group in addition to the real user’s rights when making access control decisions • enables privileged programs to access files / resources not generally accessible

  19. Traditional UNIX File Access Control • sticky bit • when applied to a directory it specifies that only the owner of any file in the directory can rename, move, or delete that file • superuser • is exempt from usual access control restrictions • has system-wide access

  20. Access Control Lists (ACLs) in UNIX • modern UNIX systems support ACLs • FreeBSD, OpenBSD, Linux, Solaris • FreeBSD • Setfacl assigns a list of UNIX user IDs and groups • any number of users and groups can be associated with a file • read, write, execute protection bits • a file does not need to have an ACL • includes an additional protection bit that indicates whether the file has an extended ACL

  21. Access Control Lists (ACLs) in UNIX • when a process requests access to a file system object two steps are performed: • step 1: selects the most appropriate ACL • owner, named users, owning / named groups, others • step 2: checks if the matching entry contains sufficient permissions

  22. Mandatory Access Control (MAC) Top Secret Labeling Mechanism is used Prevent any illegal flow of information through the enforcement of multilevel security Secret Military Security Confidential Require a strict classification of subjects and objects in security levels Drawback of being too rigid Applicable only to very few environments Unclassified dominance  can-flow Adopted from : Role-Based Access Control by Prof.RaviSandhu

  23. Compartments and Sensitivity Levels • Information access is limited by the need-to-know • Compartment: Each piece of classified information may be associated with one or more projects called compartments Top Secret Compartment 1 Secret Compartment 2 Confidential Compartment 3 Restricted Unclassified

  24. Classification & Clearance • <rank; compartments> • class of a piece of information • Clearance: an indication that a person is trusted to access information up to a certain level of sensitivity • <rank; compartments> • clearance of a subject

  25. Dominance Relation • We say that s dominates o (or o is dominated by s) if o <= s For a subject s and an object o, o <= s if and only if rank(o) <= rank(s) and compartments(o) is subset of compartments(s) • A subject can read an object if the subject dominates the object.

  26. Example • Information classified as <secret; {Sweden}> • Which of the following subject clearances can read the above information? • <top secret; {Sweden}> • <secret; {Sweden, crypto}> • <top secret; {crypto}> • <confidential; {Sweden}> • <secret; {France}>

  27. Role-Based Access Control(RBAC)

  28. AccessControlMatrix

  29. ... Role-Based Access Control Role Hierarchies Usrer-Role Assignment Permission-Role Assignment USERS ROLES PERMISSIONS Primary-Care Physician Specialist Physician Sessions Physician • Users are human beings or other active agents • Business function the user perform is role • A user can be a member of many roles • Each role can have many users as members • A user can invoke multiple sessions • In each session a user can invoke any subset of roles that the user is a member of • A permission can be assigned to many roles • Each role can have many permissions • read, write, append, execute Health-Care Provider Adopted from : Role-Based Access Control by Prof.RaviSandhu

  30. Role-Based Access Control

  31. Scope RBAC Models

  32. Example of Role Hierarchy

  33. Constraints - RBAC • provide a means of adapting RBAC to the specifics of administrative and security policies of an organization • a defined relationship among roles or a condition related to roles • mutually exclusive roles • cardinality • prerequisite roles • a user can only be assigned to one role in the set (during a session or statically) • any permission can be granted to only one role in the set • setting a maximum number with respect to roles • dictates that a user can only be assigned to a particular role if it is already assigned to some other specified role

  34. RBAC System • administrative functions • supporting system functions • review functions • provide the capability to create, delete, and maintain RBAC elements and relations • provide functions for session management and for making access control decisions • provide the capability to perform query operations on RBAC elements and relations

  35. NIST RBAC Basic Definitions • object • any system resource subject to access control, such as a file, printer, terminal, database record • operation • an executable image of a program, which upon invocation executes some function for the user • permission • an approval to perform an operation on one or more RBAC protected objects

  36. NIST RBAC Model

  37. Core RBAC • administrative functions • supporting system functions • review functions • add and delete users from the set of users • add and delete roles from the set of roles • create and delete instances of user-to-role assignment • create and delete instances of permission-to-role assignment • create a user session with a default set of active roles • add an active role to a session • delete a role from a session • check if the session subject has permission to perform a request operation on an object • enable an administrator to view but not modify all the elements of the model and their relations

  38. Hierarchical RBAC limited role hierarchies • general role hierarchies • allow an arbitrary partial ordering of the role hierarchy • impose restrictions resulting in a simpler tree structure • supports multiple inheritance, • in which a role may inherit permissions from multiple subordinate roles and • more than one role can inherit from the same subordinate role • role may have one or more immediate ascendants • but is restricted to a single immediate descendant

  39. Static Separation of Duty • enables the definition of a set of mutually exclusive roles, • if a user is assigned to one role in the set, the user may not be assigned to any other role in the set • can place a cardinality constraint on a set of roles • defined as a pair (role set, n) where no user is assigned to n or more roles from the role set • includes administrative functions for creating and deleting role sets and adding and deleting role members • includes review functions for viewing the properties of existing SSD sets

  40. Dynamic Separation of Duty • limit the permissions available to a user • places constraints on the roles that can be activated within or across a user’s sessions • define constraints as a pair (role set, n) with the property that no user session may activate n or more roles from the role set • where n is a natural number n ≤ 2 • enables the administrator to specify certain capabilities for a user at different, time spans • includes administrative and review functions for defining and viewing DSD relations

  41. Task Based Access Control Classical subject-object access control P S x O x A TBAC view of access control P S x O x A x U x AS TBAC extensions P – Permission S – Subject O – Object A – Actions U – Usage and Validity Counts AS – Authorization step • Active Security Model • Dynamic authorization gives flexibility • No Roles Involved • Constraints for this model is still under study • For each authorization step consumes permission, usage count is incremented • Usage Count reaches its limit, the associated permission is deactivated Adopted from Source: Task based authorization controls by R.S.Sandhu and R.K.Thomas

  42. Constraints User Instance Task constraints – Least Privilege Users are not given more permission than is necessary to perform their duties Constraints Achieved through task instances Permissions status Tasks Alice Check Patient Josh Initiated Active Access Permissions starts when the instance is initiated Access Permissions end when the instance is completed or revoked Revoked Fine Grained Access Control Completed

  43. Workflow Users Tasks Workflow Alice Check Patient Non-Workflow Bob Do Physical Exam Write Prescription (T5) Out Patient Workflow Do Physical Exam (T1) Check Patient (T2) Perform Lab Test (T3) View Lab Results (T4) End Start Refer another specialist (T6) Non-Workflow View Current Patient List

  44. Passive and Active Access Control Read View Current Patient List File 1 Passive Access Write File 2 Write Prescription Active Access Physician Write Prescription (T5) Workflow Do Physical Exam (T1) Check Patient (T2) Perform Lab Test (T3) View Lab Results (T4) End Start Refer another specialist (T6)

  45. Spatial and Temporal Constraints • Accessed from anywhere and at anytime • User’s location and time is taken into consideration for granting access to a task Family Practice Physician Location Constraint (Reno Office) Tasks Nurse Time Constraint (8 - 5)

  46. Static and Dynamic Separation of Duty No single individual can execute all tasks within the workflow Nurse Physician Technician Physician Alice Check Patient Josh Do Physical Exam (T1) Check Patient (T2) Perform Lab Test (T3) View Lab Results (T4) Write Prescription (T5) Task Instance 1 End Start Protects against fraudulent activities of users Static SOD - Defining the tasks in workflow or non workflow govern the administration or design-time associations between users and permissions. Dynamic SOD - permissions or task instances are granted at run-time.

  47. Delegation of Tasks Initially assigned user is not available to complete the task Supervisor can delegate task to another junior user in the same hierarchy Access rights revoked once the task is completed Senior Physician (Jan) Task Instance Task Instance Physician (Alice) Physician (Bob) Alice Bob Check Patient Josh Check Patient Josh Jan can delegate task to Bob

  48. Classification of Tasks Family Practice Senior Physician (Jan) Diagnosis Details Physician (Alice) View Current Patient List Write Prescription (T5) Do Physical Exam (T1) Check Patient (T2) Perform Lab Test (T3) View Lab Results (T4) Workflow End Start Refer another specialist (T6) ClassPrivate ClassSupervision

  49. Classification of Tasks ClassWorkflow Family Practice ClassApproval Senior Physician (Jan) Physician (Alice) Check Patient Senior Physician (Jan) Workflow Write Prescription (T5) Physician (Alice) Physician (Bob) Do Physical Exam (T1) Check Patient (T2) Perform Lab Test (T3) View Lab Results (T4) End Start Refer another specialist (T6) Same Hierarchy

  50. Attribute Based Access Control • Subject attributes • Object attributes • Environment attributes • A subject is an active entity that causes information to flow among objects or changes the system state • Attributes define the identity and characteristics of the subject • An object (or resource) is a passive information system-related entity containing or receiving information • Objects have attributes that can be leverages to make access control decisions • Describe the operational, technical, and even situational environment or context in which the information access occurs • These attributes have so far been largely ignored in most access control policies

More Related