UNIT IV ACCESS CONTROL

Access Control Principles

Access Control
Context Access
Control Policies
Subjects, Objects, and Access Rights
Role-Based Access Control
RBAC Reference Models
 Learning Objectives
After studying this chapter, you should be able to:
Explain how access control fits into the broader context that includes
authentication, authorization, and audit.
Define the three major categories of access control policies.
Distinguish among subjects, objects and access rights.
Discuss the principal concepts of role-based access control.
Summarize the RBAC model.

Two definitions of access control are useful in understanding its scope.

Access control as the process of granting or denying specific requests to:
(1) obtain and use information and related information processing services; and
(2) enter specific physical facilities.
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 (users, programs, processes, or
other systems) according to that policy.
We can view access control as the central element of computer security. The principal
objectives of computer security are to prevent unauthorized users from gaining access to
resources, to prevent legitimate users from accessing resources in an unauthorized manner, and
to enable legitimate users to access resources in an authorized manner.
In this chapter we look at three widely used techniques for implementing access control
policies.

4.1 ACCESS CONTROL PRINCIPLES

In a broad sense, all of computer security is concerned with access control. Indeed, RFC 4949
defines computer security as follows: Measures (steps) that implement and assure security services
in a computer system, particularly those that assure access control service. This chapter deals with
a narrower, more specific concept of access control: Access control implements a security
policy that specifies who or what (e.g., 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 Context (Framework)
Figure 4.1 shows a broader context of access control. In addition to access control,this context involves
the following entities and functions:
• Authentication: Verification that the credentials of a user or other system entity are
valid.
• Authorization: The granting of a right or permission to a system entity to access
system resource. This function determines who is trusted for a given purpose.
• Audit: (Assessment) An independent review and examination of system
records and activities in order to test for adequacy of system controls, to ensure
compliance with established policy and operational procedures, to detect breaches
in security, and to recommend any indicated changes in control, policy and
procedures.

An access control mechanism mediates between a user (or a process executing on behalf
of a user) and system resources, such as applications, operating systems, firewalls, routers,
files, and databases. The system must first authenticate an entity seeking access. Typically,
the authentication function determines whether the user is permitted to access the system at all.
Then the access control function determines if the specific requested access by this user is
permitted. A security administrator maintains an authorization database that specifies what
type of access to which resources is allowed for this user. The access control function consults
this database to determine whether to grant access. An auditing function monitors and keeps a
record of user accesses to system resources.
In the simple model of Figure 4.1, the access control function is shown as a single
logical module. In practice, a number of components may cooperatively share the access control
function. All operating systems have at least a rudimentary (elementary), and in many cases a quite
robust, access control component. Add-on security packages can supplement the native access
control capabilities of the operating system. Particular applications or utilities, such as a
database management system, also incorporate access control functions. External devices,
such as firewalls, can also provide access control services.

Access Control Policies

An access control policy, which can be embodied in an authorization database, dictates what
types of access are permitted, under what circumstances, and by whom. Access control
policies are generally grouped into the following categories:
• Discretionary access control (DAC): Controls access based on the identity of the
requestor and on access rules (authorizations) stating what requestors are (or are not)
allowed to do. This policy is termed discretionary'(optional) because an entity might have
access rights that permit the entity, by its own volition, to enable another entity to
access some resource.
• Mandatory access control (MAC): Controls access based on comparing security labels
(which indicate how sensitive or critical system resources are) with security clearances
(which indicate system entities are eligible to access certain resources). This policy is termed
mandatory because an entity that has clearance to access a resource may not, just by its own
volition, enable another entity to access that resource.
• Role-based access control (RBAC): 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.
• Attribute-based access control (ABAC): Controls access based on attributes of the
user, the resource to be accessed, and current environmental conditions.
DAC is the traditional method of implementing access control. MAC is a concept that
evolved out of requirements for military information security and is best covered in the context
of trusted systems. Both RBAC and ABAC have become increasingly popular.
These four policies are not mutually exclusive. An access control mechanism can
employ two or even all three of these policies to cover different classes of system resources.
4.2 SUBJECTS, OBJECTS, AND ACCESS RIGHTS

The basic elements of access control are: subject, object, and access right.
A subject is an entity capable of accessing objects. Generally, the concept of subject
equates with that of process. Any user or application actually gains access to an object by
means of a process that represents that user or application. The process takes on the
attributes of the user, such as access rights.
A subject is typically held accountable for the actions they have initiated, and
an audit trail may be used to record the association of a subject with security- relevant
actions performed on an object by the subject.
Basic access control systems typically define three classes of subject, with
different access rights for each class:
• Owner: This may be the creator of a resource, such as a file. For system resources,
ownership may belong to a system administrator. For project resources, a project
administrator or leader may be assigned ownership.
• Group: In addition to the privileges assigned to an owner, a named group of users
may also be granted access rights, such that membership in the group is sufficient
to exercise these access rights. In most schemes, 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 for this
resource.
An object is a resource to which access is controlled. In general, an object is an
entity used to contain and/or receive information. Examples include records, blocks,
pages, segments, files, portions of files, directories, directory trees, mail-boxes,
messages, and programs. Some access control systems also encompass, bits, bytes,
words, processors, communication ports, clocks, and network nodes.
The number and types of objects to be protected by an access control system
depends on the environment in which access control operates and the desired
tradeoff between security on the one hand and complexity, processing burden, and ease
of use on the other hand.
An access right describes the way in which a subject may access an object.
Access rights could include the following:
• 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.
 • Write: User may add, modify, or delete data in system resource (e.g., files,
records, programs). Write access includes read access.
• Execute: User may execute specified programs.
• Delete: User may delete certain system resources, such as files or records.
• Create: User may create new files, records, or fields.
• Search: User may list the files in a directory or otherwise search the directory.

4.â ROLE-BASED ACCESS CONTROL

Traditional DAC (Discretionary access control) systems define the access rights of
individual users and groups of users. In contrast, RBAC is based on the roles that
users assume in a system rather than the user’s identity. Typically, RBAC models
define a role as a job function within an organization. RBAC systems assign access
rights to roles instead of individual users. In turn, users are assigned to different
roles, either statically or dynamically, according to their responsibilities.
RBAC now enjoys widespread commercial use and remains an area of active research.
The National Institute of Standards and Technology (NIST) has issued a standard, that
requires support for access control and administration through roles.

The relationship of users to roles is many to many, as is the relationship of roles to

resources, or system objects (Figure 4.6). The set of users changes, in some environments
frequently, and the assignment of a user to one or more roles may also be dynamic. The set
of roles in the system in most environments is relatively static, with only occasional additions
or deletions. Each role will have specific access rights to one or more resources. The set of
resources and the specific access rights associated with a particular role are also likely to
change infrequently.

We can use the access matrix representation to depict the key elements of an RBAC system
in simple terms, as shown in Figure 4.7. The upper matrix relates individual users to roles.
Typically there are many more users than roles. Each matrix entry is either blank or marked, the
latter indicating that this user is assigned to this role. Note that a single user may be assigned
multiple roles (more than one mark in a row) and that multiple users may be assigned to a single
role (more than one mark in a column). Typically, there are few roles and many objects, or
resources. In this matrix the entries are the specific access rights enjoyed by the roles. Note that a
role can be treated as an object, allowing the definition of role hierarchies.
RBAC lends itself to an effective implementation of the principle of least privilege.
Each role should contain the minimum set of access rights needed for that role. A user is
assigned to a role that enables him or her to perform only what is required for that role.
Multiple users assigned to the same role, enjoy the same minimal set of access rights.

RBAC Reference Models

A variety of functions and services can be included under the general RBAC approach.
To clarify the various aspects of RBAC, it is useful to define a set of abstract models
of RBAC functionality.

[SAND96] defines a family of reference models that has served as the basis for
ongoing standardization efforts. This family consists of four models that are related to each
other as shown in Figure 4.8a. and Table 4.3. RBACo 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.
Base MODEL— RBAC0 Figure 4.8b, without the role hierarchy and constraints, contains the
four types of entities in an RBAC0 system:
• User: An individual that has access to this computer system. Each individual has an
associated user ID.
• Role: A named job function within the organization on that controls this computer system.
Typically, associated with each role is a description of the authority and responsibility
conferred on this role, and on any user who assumes this role.
• Permission: An approval of a particular mode of access to one or more objects. Equivalent
terms are access right, privilege, and authorization.
• Session: A mapping between a user and an activated subset of the set of roles
to which the User is assigned.
The arrowed lines in Figure 4.8b indicate relationships, or mappings, With a single
arrowhead indicating one and a double arrowhead indicating many. Thus, there is a many-to-
many relationship between users and roles: One user may have multiple roles, and multiple
users may be assigned to a single role. Similarly, there is a many-to-many relationship between
roles and permissions. 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.
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. Without this flexibility and granularity, there is a greater risk that a user may
be granted more access to resources than is needed because of the limited control over the
types of access that can be allowed. The NIST RBAC document gives the following
examples: Users may need to list directories and modify existing files without creating new
files, or they may need to append records to a file without modifying existing records.

ROLE HIERARCHIES— RBAC1 Role hierarchies provide a means of reflecting the

hierarchical structure of roles in an organization. Typically, job functions with greater
responsibility have greater authority to access resources. A subordinate job function may have a
subset of the access rights of the superior job function. Role hierarchies make use of the
concept of inheritance to enable one role to implicitly include access rights associated
with a subordinate role.
Figure 4.9 is an example of a diagram of a role hierarchy. By convention, sub- ordinate
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. For example, in
Figure 4.9, the Project Lead role includes all of the access rights of the Production
Engineer role and of the Quality Engineer role. More than one role can inherit from the same
subordinate role. For example, both the Production Engineer role and the Qualily
Engineer role include all of the access rights of the 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. Thus, these two roles have overlapping access rights,
namely the access rights they share with the Engineer role.

Constraints— RBAC2 Constraints provide a means of adapting RBAC to the specifics of

administrative and security policies in an organization. A constraint is a defined relationship
among roles or a condition related to roles. [SAND96] lists the following types of
constraints: Mutually exclusive roles, Cardinality, and Prerequisite roles.

Mutually exclusive roles are roles such that a user can be assigned to only one role in
the set. This limitation could be a static one, or it could be dynamic, in the sense that a user
could be assigned only one of the roles in the set for a session. The mutually exclusive
constraint supports a separation of duties and capabilities within an organization. This
separation can be reinforced or enhanced by use of mutually exclusive permission assignments.
With this additional constraint, a mutually exclusive set of roles has the following
properties:
1. A user can only be assigned to one role in the set (either during a session or statically).
2. Any permission (access right) can be granted to only one role in the set.
Thus the set of mutually exclusive roles have non-overlapping permissions. If two users are
assigned to different roles in the set, then the users have non-overlapping permissions while
assuming those roles. The purpose of mutually exclusive roles is to increase the difficulty of
collusion among individuals of different skills or divergent job functions to thwart security
policies.
Cardinality refers to setting a maximum number with respect to roles. One such
constraint is to set a maximum number of users that can be assigned to a given role. For example,
a project leader role or a department head role might be limited to a single user. The system
could also impose a constraint on the number of roles that a user is assigned to, or the number
of roles a user can activate for a single session. Another form of constraint is to set a maximum
number of roles that can be granted a particular permission; this might be a desirable risk
mitigation technique for a sensitive or powerful permission.
A system might be able to specify a Prerequisite role, which dictates that a user can
only be assigned to a particular role if it is already assigned to some other specified role. A
prerequisite can be used to structure the implementation of the least privilege concept. In a
hierarchy, it might be required that a user can be assigned to a senior (higher) role only if it is
already assigned an immediately junior (lower) role. For example, in Figure 4.9 a user assigned
to a Project Lead role must also be assigned to the subordinate Production Engineer and
Quality Engineer roles. Then, if the user does not need all of the permissions of the Project
Lead role for a given task, the user can invoke a session using only the required subordinate role.
Note that the use of prerequisites tied to the concept of hierarchy requires the RBAC 3
Mo d el .