Role-Based Access Control (RBAC)securesw.dankook.ac.kr/ISS19-2/2019_OS_Se_12_AC(RBAC).pdfassign users to the predefined roles. Computer security & OS lab, DKU-7-Access Control Roles

Operating System Security

Role-Based Access Control (RBAC)

Fall, 2019

Cho, Seong-je (조성제)

sjcho at dankook.ac.kr

Computer Security & OS Lab

Access Control

Access Control

DAC

-2-Computer security & OS lab, DKU

Confidentiality

Authorized to read

DAC is too flexible

Integrity

Authorized to write

Weakness of DAC: Trojan horse example

User C– owner of File F

C wants A to read, but not B

A can subvert C’s policy.

Access Control

ACLs in distributed systems

ACLs comprise lists of users (or groups)● ACL entry = user (or group) name, rights

Where users and groups are defined and registered within some administration domain.

Without group names ACLs may become unmanageable, long lists of users.

Within the administration domain where a group and its constituent users are registered, a group name can be expanded into a list of users, for checking.

How can group names be used outside the domain where the group is registered?

We generalize groups to roles and consider role-based access control (RBAC)


Access Control

Role-based access control (RBAC)

Services may classify their clients into named roles e.g.

● login service: logged-in-user (after authentication)

● patient monitoring service: surgeon, doctor, nurse, patient

● online exam service: candidate, examiner, chief examiner

● digital library service: reader, librarian, administrator

Access rights (privileges) are assigned to roles for use of services (method invocation) or more fine-grained access to individual objects or broad categories of object managed by a service

Scope of role names may be the local domain of the service, or some role names may be organization-wide, across federated domains

e.g. sales-manager used in all branches of a world-wide company

police-sergeant used in all of the 52 UK county police forces

NHS-doctor used throughout the UK NHS


RBAC

(Role-based Access Control)

• RBAC models define a role as a job function within an organization

Access Control

RBAC

RBAC models decouple the user from the resource

● User’s change frequently, Roles don’t


Access Control

RBAC

Many organizations base access control decisions on “the roles that individual users take on as part of the organization”.

role-permission relationships can be predefined, which makes it simple to assign users to the predefined roles.


Access Control

Roles in SELinux

$ seinfo –r

Roles: 14

auditadm_r

dbadm_r

guest_r

staff_r

user_r

logadm_r

object_r

secadm_r

sysadm_r

system_r

webadm_r

xguest_r

nx_server_r

unconfined_r


$ id -Z

system_u:unconfined_r:unconfined_t:s0

$ ls -Z /usr/bin/passwd

-rwsr-xr-x. root root system_u:object_r:passwd_exec_t:s0 /usr/bin/passwd

$ ls -Z /etc/shadow

----------. root root system_u:object_r:shadow_t:s0 /etc/shadow

$ ls -Z /etc/passwd

-rw-r--r--. root root system_u:object_r:passwd_file_t:s0 /etc/passwd

$ ps -Z

LABEL PID TTY TIME CMD

system_u:unconfined_r:unconfined_t:s0 22345 pts/0 00:00:00 bash

system_u:unconfined_r:unconfined_t:s0 22926 pts/0 00:00:00 ps

Access Control

RBAC

Administration: note the separation:

principals –> roles, roles –> privileges

Service developers need only specify authorization in terms of roles,

independently of the administration of principals

e.g. annual student cohort, staff leaving and joining

Users are authenticated, as always and must also prove their right to acquire/activate a role. They thus prove they are authorized to use a service

Compare with ACLs – like ACLs containing only group names.

Compare with capabilities – can a capability that proves role membership be engineered?

RBAC seems promising for fast authorization checking.


Access Control

RBAC

Roles are used to reduce the number of entitlements that must be managed.

A role is a named collection of other entitlements.

If many users need the same set of entitlements, it can be simpler to define a role that includes those entitlements and assign it, rather than the individual entitlements, to the relevant users.


Access Control

Parametrized roles

Roles may be parametrized for fine-grained access control to capture:

relationships between principals:

Policy: “only the doctor treating a patient may access the medical record”

● e.g. treating-doctor ( hospital-ID, doctor-ID, patient-ID )

patients and others may express exclusions as authorization policy

● e.g. doctor (doctor-ID)

Policy: “where doctor is not Shipman”, “where doctor is not <x> (a relative)”

Compare with ACLs containing only groups, with exclusions of individual members

● semantics of precedence of evaluation in ACLs has always been a difficult area.


Access Control

RBAC

Define roles and then specify access control rights for these roles, rather than for subjects directly.


Access Control

RBAC

• based on the roles of users in a system rather than the user’s identity


• RBAC systems assign access rights to roles instead of individual users

• users are assigned to different roles, either statically or dynamically, according to their responsibilities


control wakeup seek

owner

ownerwakeupread

ownerownercontrol

execute

write stop

owner

control

control

read *

write * seek *

R1

R2

RO

LE

S

OBJECTS

Rn

R2R1

Figure 4.7 Access Control Matrix Representation of RBAC

Rn

R2R1 Rn

F1 F1 P1 P2 D1 D2

U1

U2

U3

U4

U5

U6

Um

Access Control Matrix Representation of RBAC

RBAC A user has access to an

object based on the assigned role.

Roles are defined based on job functions.

Permissions are defined based on authorities and responsibilities of a job.

Operations on an object are invocated based on the permissions.

Access Control

RBAC Models

Role: A named job function within the organization that controls this

computer system

● One user may have multiple roles, and multiple users may be assigned to a single role.

Permission: 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

● A session is used to define a temporary one-to-many relationship between a user and one or more of the roles to which the user has been assigned.

● The user establishes a session with only the roles needed for a particular task; this is an example of the concept of least privilege.

● Sessions: Each session is a mapping of one user to possibly many roles

− User Sessions: The mapping of user u onto a set of sessions.

− Available Session Permissions: Permissions available to a user in a session.

− Session Roles: The mapping of session s onto a set of roles


Access Control

Scope RBAC Models

The many-to-many relationships between users and roles and between roles and permissions provide a flexibility and granularity of assignment not found in conventional DAC schemes.


Access Control

Permissions

(a) Relationship among RBAC models

(b) RBAC models

RBAC0

Base model

RBAC3

Consolidated model

RBAC1

Role hierarchies

RBAC2

Constraints

Figure 4.8 A Family of Role-Based Access Control Models.

Users

user_sessions session_roles

(UA) User

Assignment

(PA) Permission

Assignment

(RH) Role

Hierarchy

Sessions

Objects

Oper-

ations

Roles

RBAC Models


• Role hierarchies: enable on role to inherit permissions from another role

• Constraints: restrict the ways in which the components of a RBAC system may be configured

Access Control

RBAC Models

RBAC0 : Base model

● User, roles, permission, session

RBAC1 : Role Hierarchies

● Allow inheritance

RBAC2 : Constraints

● Mutually exclusive roles (separation of duties)

● Cardinality (e.g., only one manager per project, only a certain number of roles for each user)

● Prerequisite (You must have a subordinate role – allows implementation of least privilege)

RBAC3 : RBAC1 + RBAC2

● Combining hierarchies with constraints


Access Control

RBAC1 (Role Hierarchies)


Subordinate roles are lower in the diagram.

A line between two roles implies that the upper role includes all of the access rights of the lower role, as well as other access rights not available to the lower role.

One role can inherit access rights from multiple subordinate roles.

Project Lead role includes all of the access rights of Production Engineer role and of Quality Engineer role.

More than one role can inherit from the same subordinate role.

● Both Production Engineer role and Quality Engineer role include all of the access rights of Engineer role

● Additional access rights are also assigned to the Production Engineer Role and a different set of additional access rights are assigned to the Quality Engineer role.

Access Control

Hierarchical Roles (RBAC1)


User inheritance

– r1r2 means every user that is a member of r1 is also a member of r2

Permission inheritance

– r1r2 means every permission that is authorized for r2 is also authorized r1

Health-Care Provider

Physician

Primary-CarePhysician

SpecialistPhysician

Engineer

HardwareEngineer

SoftwareEngineer

SupervisingEngineer

Activation inheritance

– r1r2 means that activating r1 will also activate r2

Permission and Activation inheritance have different effect when there are constraints about activation.

Access Control

RBAC2 (Constraints)


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

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

cardinality

• setting a maximum number (of users) with respect to roles

• can impose a constraint on the number of roles that a user is assigned to

prerequisite roles

• dictates that a user can only be assigned to a particular role if it is already assigned to some other specified role

• A user must be a student before having the DKU role

Access Control

RBAC2: Constraints


Example constraints● Mutual exclusion (Mutually exclusive roles)

This constraint supports separation of duties and capabilities within an organization

The purpose is to increase the difficulty of collusion among individuals of different skills or divergent job functions to thwart security policies

− Static Exclusion: No user can hold both roles• often referred to as Static Separation of Duty constraints

• Preventing a single user from having too much permissions

− Dynamic Exclusion: No user can activate both roles in one session• Often referred to as Dynamic Separation of Duty constraints

• Interact with role hierarchy interpretation

● Pre-condition: Must satisfy some condition to be member of some role

− E.g., a user must be an undergrad student before being assigned the DKU role

Access Control

RBAC2: Constraints


Example constraints● Cardinality

− On User-Role Assignment

• at most k users can belong to the role

• at least k users must belong to the role

• exactly k users must belong to the role

− On activation

• at most k users can activate a role

• …

Constraints are used for laying out higher level organization policy

● Only a tool for convenience and error checking when admin is centralized

− Not absolutely necessary if admin is always vigilant, as admin can check all organization policies are met when making any changes to RBAC policies

● A tool to enforce high-level policies when admin is decentralized

The NIST RBAC Model

administrative functions

• provide the capability to create, delete, and maintain RBAC elements and relations

supporting system

functions

• provide functions for session management and for making access control decisions

review functions

• provide the capability to perform query operations on RBAC elements and relations

RBAC System and Administrative Functional Specification

Access Control

NIST RBAC Model


Separation of Duties (SD)• Enforces conflict of interest policies

employed to prevent users from exceeding a reasonable level of authority for their position.

The NIST RBAC Model: Core 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

The NIST RBAC Model: Core RBAC

administrative 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

supporting system functions

• 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

review functions

• enable an administrator to view but not modify all the elements of the model and their relations

The NIST RBAC Model: Hierarchical RBAC

general role hierarchies

allow an arbitrary partial ordering of the role hierarchy

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

limited role hierarchies

impose restrictions resulting in a simpler tree

structure

role may have one or more immediate ascendants but

is restricted to a single immediate descendant

Role r1 is said to be a descendant of r2 if r1 includes (inherits) all of the permissions

from r2 and all users assigned to r1 are also assigned to r2.3. (r1의 권한이 더 많음)

The NIST RBAC Model

Static Separation of Duty (SSD) relations

SSD places restrictions on the set of roles and in particular on their ability to form UA relations

defined as a pair (role set, n) where no user is assigned to n or more roles from the role set – where n or more roles conflict with each other

enables the definition of a set of mutually exclusive roles, such that 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

includes administrative functions for creating and deleting role sets and adding and deleting role members

You can enforce a policy that states that a role cannot be both a purchaser and an approver of the same product, or that the person implementing firewall changes cannot audit those same changes

RBAC can ensure that users cannot be members of both the purchasing role and the approving role.

That is how SSD ensures that the same person cannot purchase and approve the purchase.

Access Control

The NIST RBAC Model

Dynamic Separation of Duties (DSD) ● Places constraints on the users that can be assigned to a set of roles,

thereby reducing the number of potential permissions that can be made available to a user

● Constraints are across or within a user’s session

DSD allows the same person to be in the purchasing role and the approving role, but they would be prohibited from approving their own purchase.● They would only be able to approve the purchases of others.

● Another example would be restricting the person who made firewall configuration changes from auditing and approving those same changes.

In the SSD model, a user may not be members of both roles.

In the DSD model, a user could be a member of both roles, but could not function in both capacities for the same linked transactions.


The NIST RBAC Model

Dynamic Separation of Duty Relations (DSD)

limit the permissions available to a user

places constraints on the roles that can be activated within or across a user’s sessions

No user may activate n or more roles from the roles set in each user session

define constraints as a pair (role set, n), where n is a natural number n ≤ 2, with the property that no user session may activate n or more roles from the role set

enables the administrator to specify certain capabilities for a user at different, non-overlapping spans of time

includes administrative and review functions for defining and viewing DSD relations

Access Control

Functions and Roles for Banking Example


Roles within the organization are defined by a combination of official position and job function

Access Control

Functions and Roles for Banking Example


Permission assignments

● The Group Manager role (role B) has more access rights than the Clerk role (role A)

No Hierarchy Hierarchy (RBAC1) - Inheritance

Figure 4.12Example of Access Control Administration

Access Control

Advantages of RBAC

RBAC allows efficient security management

● RBAC supports entitlement hierarchies

● RBAC supports dynamic entitlement inheritance

● User’s change more frequently than roles, easy revocation of rights

Principle of least privilege allows minimizing damage● Roles allow a user to sign on with the least privilege required for the particular task at hand

Separation of Duty constraints to prevent fraud● No single principles should be given enough privileges to misuse the system on their own

RBAC allows a holistic view at corporation

RBAC enables to answer questions on corporate level, e.g., which resources user B has access to?

RBAC can be implemented across different platforms

Policies implemented by an RBAC model are easy to verify

Encompasses DAC and MAC policies

● RBAC can be used to implement DAC, MAC


Access Control

Disadvantages of RBAC

Major disadvantage: Role explosion

Reasons:● Roles cannot express ownership and time

− Requires roles like “owns_docA”, “owns_docB”, etc.

● Reality is too find-grained

− Often small differences between different persons in the same job, leading to yet another role (e.g., “secretary_with_colorprint”)

● Cross-product of multiple hierarchies

− E.g., “sales_manager_for_Belgium_with_colorprint_owns_docA”

To address this:● In practice: pragmatic choice for RBAC + ownership


SELinux

(Role-based Access Control)


Access Control

SELinux User, Role, Domain


user1

user2

user 3

user1_u

user2_u

user3_u

user1_r

user3_r

user1_t

user2_t

pppd_t

nscd_t

obex_t

user_t

…_t

user3_t

…_t

Linux usersSELinuxUsers

SELinuxRoles

SELinuxDomains

Access Control

Basic concepts

Users

● SELinux users do not change during a user session, whereas a Linux user might change via su or sudo.

Roles

● A SELinux user may be allowed to take on one or more roles.

● What a role means is defined by the policy, but examples of roles are an unprivileged user, a web administrator, and a database administrator.

● Objects typically have the role object_r.

● By convention, roles have the suffix "_r", such as user_r.

Types

● This is the primary means of determining access

● The type of a process is also referred to as its domain.

● By convention, a type has the suffix "_t", such as user_t.

Contexts

● Every process and object in the system has a context (also known as a label).


user:role:type:range system_u: system_r: xserver_t: s0-s0:c0.c1023

Access Control

Roles in SELinux

These roles determine what SELinux allows the user to do

● object_r: a generic role used for files (on persistent storage and network file systems)

● webadm_r can only administrate SELinux types related to the Apache HTTP Server.

● dbadm_r can only administrate SELinux types related to the MariaDB database and the PostgreSQL database management system.

● logadm_r can only administrate SELinux types related to the syslog and auditlogprocesses.

● secadm_r can only administrate SELinux.

● auditadm_r can only administrate processes related to the audit subsystem.

● unconfined_r: This role is not confined by SELinux except by memory protections (for example executable memory protections).

To list all available roles, run the command

$ seinfo -r


Access Control

Basic concepts

Contexts● Every process and object in the system has a context (also known as a

label).

● This is an attribute used to determine if an access should be allowed between a process and an object.

● E.g.) a user process might have the context of user_u:user_r:user_t,

− file in the user's home directory might have the context of user_u:object_r:user_home_t.

● A SELinux context consists of three required fields, and one optional field:

− The first field is the SELinux user.

− The second field is the role.

− The third field in the type.

− The forth field is the MLS range; this field is optional


user:role:type:range system_u: system_r: xserver_t: s0-s0:c0.c1023

Access Control

SELinux user domains

Regular Linux useruser $ id -Z

uid=1000(swift) gid=100(users) groups=100(users),16(cron),...,995(gorg) context=user_u:user_r:user_t

The user is inside the user_t domain

Root userroot # id -Zroot:sysadm_r:sysadm_t

The root user is inside the sysadm_t domain

SELinux policy dictates that the regular user domain (user_t) is an unprivileged domain:

● it should never be allowed to do any administrative tasks.

● Even if you grant this user root access (through sudo or su), the user will not be able to do much damage to the system.

● This isn't only because of the user_t domain however - it is also because of the SELinux role that that user is in.


Access Control

Role part in the context


user_u: user_r: user_t

The SELinux role dictates what domains (contexts) are possible to be in.

● It doesn't mean that the user can freely choose which domains he launches in next (there are still the domain transitions that govern this);

● it means that, even if he was allowed to transition, if the domain is not attached to his role, the transition will fail.

With the seinfo tool, you can list what domains are allowed for a particular role

user $ seinfo -ruser_r -xuser_r

Dominated Roles: user_r

Types: chromium_renderer_tuser_gkeyringd_t ...

Access Control

Switching roles


user $ id –z ①user_u: user_r: user_t

Users can switch roles if they want.● However, they can only do so if their SELinux user is allowed to "be" in the other role.

● With semanage user -l you can see if that is the case.

root # semanage user -lSELinux User SELinux Roles root staff_r sysadm_rstaff_u staff_r sysadm_rsysadm_u sysadm_rsystem_u system_runconfined_u unconfined_ruser_u user_r

The user ① is only allowed to be in the user_r role.

● In other words, this user is not able to switch roles.

The user ② could switch from the sysadm_r role to the staff_r role (and vice versa).

Switching roles is done using newrole -r <targetrole>.

● It is most commonly used to switch from the staff_r role to the sysadm_r role:

root # id –z ②root: sysadm_r: sysadm_t

user $ newrole -r sysadm_rPassword:

Summary

access control prevent unauthorized users from gaining access to resources

prevent legitimate users from accessing resources in an unauthorized manner

enable legitimate users to access resources in an authorized manner

subjects, objects, access rights

authentication, authorization, audit

discretionary access controls (DAC) controls access based on identity

mandatory access control (MAC) controls access based on security labels

role-based access control (RBAC) controls access based on roles

Documents

Role-Based Access Control (RBAC)securesw.dankook.ac.kr/ISS19-2/2019_OS_Se_12_AC(RBAC).pdfassign users to the predefined roles. Computer security & OS lab, DKU-7-Access Control Roles