Chapter 4 Access Control

Chapter 4 Access Control

Access Control Definition RFC 4949 defines computer security as: “Measures that implement and assure security services in a computer system, particularly those that assure access control service.” NIST IR 7298 defines access control as: “a process by which use of system resources is regulated according to a security policy and is permitted only by authorized entities”

Authentication vs. Authorization Authentication Are you who you say you are? – Restrictions on who (or what) can access system Authorization Are you allowed to do that? – Restrictions on actions of authenticated users Authorization is a form of access control Classic view of authorization – Access Control Lists (ACLs) – Capabilities (C-lists) – Access Control implements a security policy that specifies who (or what in the case of a process) may have access to each specific system resource and the type of access that is permitted in each instance.

Access Control Principles Authentication: Verification that the credentials of a user or other system entity are valid. Authorization: Granting of a right or permission to a system entity to access a system resource o determines who is trusted for a given purpose. Audit: An independent review and examination of system records and activities in order to o o o o test for adequacy of system controls ensure compliance with established policy and operational procedures detect breaches in security to recommend any indicated changes in control, policy and procedures.

Authorization database Security administrator Authentication Authentication function Accesscontrol Access control function User System resources Auditing Figure4.1 Relationship AmongAccess Control and Other Security Functions

Access Control The central element of computer security. The principal objectives of computer security are o to prevent unauthorized users from gaining access to resources, o to prevent legitimate users from accessing resources in an unauthorized manner, o and to enable legitimate users to access resources in an authorized manner

Lampson’s Access Control Matrix This matrix contains all of the relevant information needed by an OS to make decisions about which users are allowed to do with the various system resources o Subjects (users) index the rows o Objects (resources) index the columns OS Accounting program Accounting data Insurance data Payroll data rx rx r Alice rx rx r rw rw rwx rwx r rw rw rx rx rw rw rw Bob Sam Accounting program The model assumes a set of subjects, a set of objects, and a set of rules that govern the access of subjects to objects.

Access Control Policies 1) Discretionary Access Control (DAC) o Controls access based on the identity of the requestor and on access rules (authorizations) stating what requestors are (or are not) allowed to do (the owner of the access permission can pass it to others). 2) Mandatory Access Control (MAC) o Controls access based on comparing security labels with security clearances (subject clearance and object labels) 3) Role-Based Access Control (RBAC) o Controls access based on the roles that users have within the system and on rules stating what accesses are allowed to users in given roles 4) Attribute-Based Access Control (ABAC) o Controls access based on attributes of the user, the resource to be accessed, and current environmental conditions Note: these four policies are not mutually exclusive. An access control mechanism can employ two or even all of these policies to cover different classes of system resources.

Subjects, Objects, and Access Rights The basic elements of access control are: subject, object, and access right. Subject An entity capable of accessing objects. Held accountable for all actions Three classes Owner Group World Object Access right A resource to which access is controlled Describes the way in which a subject may access an object Entity used to contain and/or receive information Could include: Read Write Execute Delete Create Search

Subjects & Objects A subject is typically held accountable for the actions they have initiated o an audit track may be used to record the association of a subject with security relevant actions performed on an object by the subject. Owner: This may be the creator of a resource, such as a file. E.g. a project administrator or leader may be assigned ownership. Group: a named group of users may also be granted access rights, E.g. membership in the group is sufficient to exercise these access rights. a user may belong to multiple groups. World: The least amount of access is granted to users who are able to access the system but are not included in the categories owner and group An object is a resource to which access is controlled. o entity used to contain and/or receive information. o E.g. records, blocks, pages, segments, files, portions of files, directories, directory trees, mailboxes, messages, and programs

Access Right Describes the way in which a subject may access an object o Read: User may view information in a system resource. E.g. a file, selected records in a file, selected fields within a record, or some combination). Read access includes the ability to copy or print. o Write: User may add, modify, or delete data in system resource E.g. files, records, programs. o Execute: User may execute specified programs. o Delete: User may delete certain system resources, such as files or records. o Create: User may create new files, records, or fields. o Search: User may list the files in a directory or otherwise search the directory.

Discretionary Access Control (DAC) Traditional method of implementing access control Scheme in which an entity may enable another entity to access some resource o i.e. applied by operating system or a database management system Often provided using an access matrix (Lampson’s Access Control Matrix) o One dimension consists of identified subjects that may attempt data access to the resources o 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

Simple Example of an Access Matrix OBJ ECTS File1 User A SUBJ ECTS File2 Own Read Write User B Read User C Read Write File3 File4 Own Read Write Own Read Write Write Read (a) Access matrix Read Own Read Write E.g. User A owns files 1 and 3 and has read and write access rights to those files. User B has read access rights to file 1, etc.

Access Control Lists (ACLs) ACL: store Lampson's access control matrix by column E.g.: ACL for insurance data is in blue ACLs are preferable when: o users manage their own files and o protection is data oriented. With ACLs, it's also easy to change rights to a particular resource. OS Accounting program Accounting data Insurance data Payroll data rx rx r Alice rx rx r rw rw rwx rwx r rw rw rx rx rw rw rw Bob Sam Accounting program

Capabilities (or C-Lists) Store access control matrix by row E.g.: Capability (C-List) for Alice is in red With C-Lists, it is easy to delegate (and sub-delegate and sub-subdelegate, and so on), and it is easier to add or delete users. OS Accounting program Accounting data r rw rwx r rw rw rx rw rw rw rx r Alice rx rx rwx rx Accounting program Payroll data rw Bob rx Sam Insurance data

ACLs vs. Capabilities Alice r --r Bob w r --- Fred rw r r file1 file2 file3 Alice r w rw file1 Bob --r r file2 Fred r --r file3 Access Control List (ACL) Note that arrows point in opposite directions With ACLs, still need to associate users to files Capability (C-List)

(a) Access matrix ACL File1 File2 A Own R W C-List B C R R W B Own R W C A Own R W B User A User B R B R Own R W Own R W File1 File2 File3 File4 R Own R W W R File1 File2 File4 R W R Own R W W File4 File3 File3 File1 C Own R W User C (c) Capability lists for files of part (a) In practice, an access matrix is usually sparse and is (b) Access control listsfor files of part (a) implemented by decomposition in one of two ways. Figure4.2 Exampleof Access Control Structures

Table 4.1 Authorization Table for Files in Figure 4.2 Each row for one access right of one subject to one resource A data structure that is not sparse More convenient than either ACLs or C-lists Sorting this table by subject is equivalent to a C-List Sorting this table by object is equivalent to an ACL

A General Model for DAC The model assumes: o a set of subjects, o a set of objects, and o a set of rules that govern the access of subjects to objects. Protection state of a system to be the set of information, at a given point in time, that specifies the access rights for each subject with respect to each object. We can identify three Requirements: o representing the protection state, o enforcing the access rights, o and allowing subjects to alter the protection state in certain ways.

A Each entry A[S, X] contains strings, called access attributes, that specify the access rights of subject S to object X. Extend the universe of objects in the access control matrix to the following: Processes: Access rights: ability to delete, stop (block), and wake up a process. Devices: Access rights: ability to read/write, to control and to block/unblock its use. Memory locations or regions: Access rights: ability to read/write certain regions Subjects: Access rights with respect to a subject have to do with the ability to grant or delete access rights of that subject to other objects, subjects can alter the protection state in certain ways

Every access by a subject to an object is mediated by the controller for that object, The controller’s decision is based on the current contents of the matrix. Certain subjects have the authority to make specific changes to the access matrix. A request to modify the access matrix is treated as an access to the matrix

Modifying the Access Control Rules are needed to govern the modifications to the access matrix. Thus, we introduce to the access rights: 1. ‘owner’ and 2. ‘control’ 3. and the concept of a copy flag. These rules deal with 1) transferring, 2) granting, and 3) deleting access rights. Eg. Suppose that the entry α* exists in A[S0, X]. This means that S0 has access right α to object X. Because of the copy flag, S0 can transfer this right, with or without copy flag, to another subject. o Rule R1 in the following slide expresses this capability

Rule Command (by So) R1 ì a* ü transfer í ý to S, X a î þ 'a*' in A[So, X] ìa *ü grant í ý to S, X îa þ 'owner' in A[So, X] R2 Authorization Operation ìa *ü store í ý in A[S, X] îa þ ì a* ü store í ý in A[S, X] a î þ 'control' in A[So, S] R3 or deletea from S, X delete a from A[S, X] 'owner' in A[So, X] Table 4.3 Access Control System Commands 'control' in A[So, S] R4 or w read S, X copy A[S, X] into w 'owner' in A[So, X] R5 createobject X None add column for X to A; store 'owner' in A[So, X] R6 destroy object X 'owner' in A[So, X] delete column for X from A none add row for S to A; execute createobject S; store 'control' in A[S, S] 'owner' in A[So, S] delete row for S from A; execute destroy object S R7 R8 createsubject S destroy subject S (Table is on page 116 in the textbook)

Rule R1: α exists in A[S0, X] means that subject S0 has access right α to object X α* (* is the copy flag) means that S0 can transfer this right, with or without copy flag, to another subject (copy flag should be carefully transferred). Rule R2 states that subject S0 can add any access right to A[S, X] for any subject S, if S0 has ‘owner’ access to X. Rule R3 permits S0 to delete any access right from any matrix entry in a row for which S0 has the control right of the subject S or for any matrix entry in a

Rule R4 states that S0 can permits the subject S to read that portion of the matrix that it owns or controls. Rule R5 states that any subject can create a new object, which it owns, and can then grant and delete access to the object. Rule R6; the owner of an object can destroy the object, resulting in the deletion of the corresponding column of the access matrix.

Rule R7 enables any subject to create a new subject; the creator owns the new subject and the new subject has control access to itself. Rule R8 permits the owner of a subject to delete the row and column (if there are subject columns) of the access matrix designated by that subject.

UNIX File Access Control UNIX files are administered by the OS 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; each file is controlled by exactly one inode 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

UNIX s ss ss as a l l a l c c c r p r e u e n w ro th O G O File Access Control Unique user identification number (user ID) Member of a primary group identified by a group ID Belongs to a specific group rw- r- - --- user : : rwgroup: : r- ot her: : - - (a) Traditional UNIX approach (minimal access control list) 12 protection bits s ss ss as a l l a l c rc p rc e u e n w ro th O G O 9 of the protection bits specify read, write, and execute permission for the owner of the file, members of the group and all other users The owner ID, group ID, and masked protection bits are part of the file’s entries inode rwuser: : rwuser: j oe: rwgroup: : r- mask: : r wot her : : - - - rw- ---

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 Sticky bit Any program that is owned by, and SetUID to, the “superuser” potentially granted unrestricted access to the system to any user executing that program When applied to a directory it specifies that only the owner of the file in the directory can rename, move, or delete that file Superuser (root) Is exempt from usual access control restrictions Has system-wide access

When a process requests access to a file: Step 1 selects the ACL entry that most closely matches the requesting process. ACL entries are looked at the order: owner, named users, groups, & others. Only a single entry determines access. Step 2 checks if the matching entry contains sufficient permissions. A process can be a member of more than one group; so more than one group entry can match. If any of these matching group entries contain the requested permissions, one that contains the requested permissions is picked (the result is the same no matter which entry is picked). If none of the matching group entries contains the requested permissions, access will be denied no matter which entry is picked.

Role-Based Access Control (RBAC) Traditional DAC systems define the access rights of individual users and groups of users. In contrast, RBAC is based on: o Roles that users assume in a system (instead of their Identity) o Role is a job function within an organization. A role will have specific access rights to one or more resources. o Assign Access Rights to Roles (instead of individual users.) o Users assigned to different Roles according to their Responsibilities. o Users-to-Roles are Many-to-Many. The set of Users changes frequently (dynamic), and the assignment of a user to one or more roles may also be dynamic. The set of Roles is relatively static, with only occasional additions or deletions. The set of Resources and the specific access rights associated with a particular role are also likely to change infrequently (relatively static).

Users Roles Access rights are assigned to Roles instead of individuals Users are assigned to Roles. (statically or dynamically, Based on responsibilities) Users to Roles are Many-to-Many Users may change frequently Often, Roles are static A Role has specific access rights Role1 Role2 Role3 Figure4.6 Users, Roles, and Resources Resources

Best practice for using RBAC RBAC allows to o Segregate duties within a team and o Grant only the amount of access to users that they need to perform the jobs. Instead of giving everybody (group) unrestricted permissions on a resource, you can allow only certain actions at a particular scope. Planning the access control strategy, it’s a best practice to grant users the least privilege to get their work done. o Each role should contain the minimum set of access rights needed for that role. A role assignment consists of three elements: o Security principal, (object that represents a user, group, service principal) o Role definition, (collection of permissions.) o Scope, (set of resources that the access applies to)

Relates individual users to roles Typically there are many more users than roles Each entry is either blank or marked R1 Typically, few Roles & many Users, Rn U1 U2 U3 A user may be assigned multiple roles U4 U5 A role contains the minimum set of access rights. U6 A user is assigned to a role that enables him/her to perform only what is required. Um Multiple users may be assigned to the same Role. OBJ ECTS ROLES R1 has the same structure as the DAC access control matrix, with roles as subjects R2 R2 Rn R1 R2 Rn F1 F1 control owner owner control read * read owner write* execute control control write P1 P2 wakeup wakeup D1 D2 seek owner owner seek * stop Figure4.7 Access Control Matrix Representation of RBAC

Abstract models of RBAC functionality RBAC3 Consolidated model Role: A named job function within the organization that controls this computer system. (authority & responsibility) RBAC1 Rolehierarchies Permission: An approval of a particular mode of access to one or more objects. (access right, privilege, authorization). RBAC0 Basemodel Session: A mapping between a user and an activated subset of the set of roles to which the user is assigned. (a) Relationship among RBAC models Temporary one-to-many relationship (RH) Role Hierarchy Least privilege: Only needed roles One user may have multiple roles, and multiple users may be assigned to a single role (many-to-many). Users (UA) User Assignment user sessions Flexibility and granularity: the many-to-many relationships between users and roles and between roles and permissions (not found in conventional DAC schemes). Without this flexibility and granularity, there is a risk that a user may be granted more access to resources than is needed RBAC2 Constraints Roles Operations (PA) Permission Assignment Permissions session roles Objects Sessions (b) RBAC models without the role hierarchy and constraints, contains the four types of entities in an RBAC0 system: Figure4.8 A Family of Role-Based Access Control Models.

Table 4.3 Scope RBAC Models RBAC0 contains the minimum functionality for an RBAC system RBAC1 includes the RBAC0 functionality and adds role hierarchies, which enable one role to inherit permissions from another role RBAC2 includes RBAC0 and adds constraints, which restrict the ways in which the components of a RBAC system may be configured RBAC3 contains the functionality of RBAC0, RBAC1, and RBAC2

An example of a diagram of a role Hierarchy Role hierarchies reflect the hierarchical structure of roles in an organization. A line between two roles implies that the upper role includes all of the access rights of the lower role, Typically, job functions with greater responsibility have greater authority to access resources Role hierarchies make use of the concept of inheritance to enable one role to implicitly include access rights associated with a subordinate role.

Constraints - RBAC Provide a means of adapting RBAC to the specifics of administrative and security policies of an organization A constraint is a defined relationship among roles or a condition related to roles. Types: Mutually Exclusive Roles A user can only be assigned to one role in the set (either during a session or statically) Any permission (access right) can be granted to only one role in the set Separation of duties and capabilities (no collusion among individuals, roles have non-overlapping permissions) Cardinality Setting a maximum number with respect to roles. E.g. Constraint the maximum number of users that can be assigned to a given role the number of roles that a user is assigned to, the number of roles a user can activate for a single session Prerequisite Roles Dictates that a user can only be assigned to a particular role if it is already assigned to some other specified role E.g. can be used to structure the impl. of the least privilege concept

Attribute-based Access Control (ABAC) ABAC is a logical access control model that controls access to objects by evaluating rules against the attributes of entities (subject and object), operations, and the environment relevant to a request. Define authorizations that express conditions on properties of both the resource and the subject o E.g. consider a configuration in which each resource has an attribute that identifies the subject that created the resource. o Then, a single access rule can specify the ownership privilege for all the creators of every resource Pros: o The strength of the ABAC approach is its flexibility and expressive power Cons: o Main obstacle to its adoption in real systems has been concern about the performance impact of evaluating predicates on both resource

Attribute-Based Access Control (ABAC) Main obstacle to its Web services have adoption in real Can define been pioneering systems has been There is authorizations technologies Strength is its concern about the considerable that express through the interest in flexibility and performance impact conditions on introduction of expressive of evaluating applying the properties of both the eXtensible predicates on both power model to cloud the resource and Access Control resource and user services the subject Markup Language properties for each (XAMCL) access

ABAC Model: Attributes Subject 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 Object attributes An object (or resource) is a passive information system-related entity containing or receiving information Objects have attributes that can be leveraged to make access control decisions Environment attributes 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

current set of rules to determine authorization

Summary Access control principles o Access control context o Access control policies Subjects, objects, and access rights Discretionary access control o Access control model o Protection domains UNIX file access control o Traditional UNIX file access control o Access control lists in UNIX Role-based access control o RBAC reference models Attribute-based access control o Attributes o ABAC logical architecture o ABAC policies Identity, credential, and access management o o o o Identity management Credential management Access management Identity federation Trust frameworks o Traditional identity exchange approach o Open identity trust framework Bank RBAC system