Chapter 4 Access Control Access Control Definition RFC

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 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.

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 q 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 Insurance program data Payroll data Bob rx rx r Alice rx rx r rw rw Sam rwx r rw rw rx rx rw rw rw 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 Object A resource to which access is controlled Describes the way in which a subject may access an object Could include: Three classes • Owner • Group • World Access right Entity used to contain and/or receive information • • • 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 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) q ACL: store Lampson's access control matrix by column E. g. : ACL for insurance data is in blue q ACLs are preferable when: q o users manage their own files and o protection is data oriented. q With ACLs, it's also easy to change rights to a particular resource. OS Accounting Insurance program data Payroll data Bob rx rx r Alice rx rx r rw rw Sam rwx r rw rw rx rx rw rw rw Accounting program

Capabilities (or C-Lists) q q q 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 Insurance program data Payroll data Bob rx rx r Alice rx rx r rw rw Sam rwx r rw rw rx rx rw rw rw Accounting program

ACLs vs. Capabilities Alice r --r Bob w r --- Fred rw r r file 1 file 2 file 3 Alice r w rw file 1 Bob --r r file 2 Fred r --r file 3 Access Control List (ACL) • Note that arrows point in opposite directions… • With ACLs, still need to associate users to files Capability (C-List)

ACL C-List In practice, an access matrix is usually sparse and is implemented by decomposition in one of two ways.

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[S 0, X]. This means that S 0 has access right α to object X. • Because of the copy flag, S 0 can transfer this right, with or without copy flag, to another subject. o Rule R 1 in the following slide expresses this capability

Table 4. 3 Access Control System Commands (Table is on page 116 in the textbook)

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

• Rule R 4 states that S 0 can permits the subject S to read that portion of the matrix that it owns or controls. • Rule R 5 states that any subject can create a new object, which it owns, and can then grant and delete access to the object. • Rule R 6; the owner of an object can destroy the object, resulting in the deletion of the corresponding column of the access matrix.

• Rule R 7 enables any subject to create a new subject; the creator owns the new subject and the new subject has control access to itself. • Rule R 8 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 File Access Control Unique user identification number (user ID) Member of a primary group identified by a group ID Belongs to a specific group 12 protection bits 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 protection bits are part of the file’s inode

Traditional UNIX File Access Control “Set user ID”(Set. UID) “Set group ID”(Set. GID) 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 Set. UID 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).

• 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

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 • A user may be assigned multiple roles • A role contains the minimum set of access rights. • A user is assigned to a role that enables him/her to perform only what is required. • Multiple users may be assigned to the same Role. • has the same structure as the DAC access control matrix, with roles as subjects Typically, few Roles & many Users,

Abstract models of RBAC functionality • Role: A named job function within the organization that controls this computer system. (authority & responsibility) • Permission: An approval of a particular mode of access to one or more objects. (access right, privilege, authorization). • Session: A mapping between a user and an activated subset of the set of roles to which the user is assigned. • Temporary one-to-many relationship • Least privilege: Only needed roles • One user may have multiple roles, and multiple users may be assigned to a single role (many-to-many). • 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 without the role hierarchy and constraints, contains the four types of entities in an RBAC 0 system:

Table 4. 3 Scope RBAC Models • RBAC 0 contains the minimum functionality for an RBAC system • RBAC 1 includes the RBAC 0 functionality and adds role hierarchies, which enable one role to inherit permissions from another role • RBAC 2 includes RBAC 0 and adds constraints, which restrict the ways in which the components of a RBAC system may be configured • RBAC 3 contains the functionality of RBAC 0, RBAC 1, and RBAC 2

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 and user properties for each access.

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

ABAC Model: Attributes Subject attributes Object attributes • A subject is an active entity that causes information to flow among objects or changes the system state • An object (or resource) is a passive information systemrelated entity containing or receiving information • Attributes define the identity and characteristics of the subject • 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 Identity management Credential management Access management Identity federation • Trust frameworks o Traditional identity exchange approach o Open identity trust framework • Bank RBAC system