Goals of Protection

As computer systems have become more sophisticated and pervasive in their

applications, the need to protect their integrity has also grown.
Protection was originally conceived as an adjunct to multiprogramming
operating systems, so that untrustworthy users might safely share a common
logical name space, such as a directory of files, or share a common physical
name space, such as memory.
Modern protection concepts have evolved to increase the reliability of any
complex system that makes use of shared resources.
We need to provide protection for several reasons.
 The most obvious is the need to prevent the mischievous, intentional
violation of an access restriction by a user.
 Protection is the need to ensure that each program component active in a
system uses system resources only in ways consistent with stated policies.
 Protectioncanimprovereliabilitybydetectinglatenterrorsattheinterfaces
between component subsystems.
 The role of protection in a computer system is to provide a mechanism
for the enforcement of the policies governing resource use. These policies
can be established in a variety of ways. Some are fixed in the design of
the system, while others are formulated by the management of a system.
 Policies for resource use may vary by application, and they may change
over time. For these reasons, protection is no longer the concern solely of
the designer of an operating system.
 The application programmer needs to use protection mechanisms as well,
to guard resources created and supported by an application subsystem
against misuse.
Access Matrix:
protection can be viewed abstractly as a matrix, called an access matrix.
The rows of the access matrix represent domains, and the columns represent
objects.
Each entry in the matrix consists of a set of access rights.
Because the column defines objects explicitly, we can omit the object name
from the access right.
The entry access(i,j) defines the set of operations that a process executing in
domain Di can invoke on object Oj.
There are four domains and four objects—three files (F1, F2, F3) and one laser
printer. A process executing in domain D1 can read files F1 and F3. A process
executing in domain D4 has the same privileges as one executing in domain D1;
but in addition, it can also write onto files F1 and F3.Thelaser printer can be
accessed only by a process executing in domain D2.
The access-matrix scheme provides us with the mechanism for specifying a
variety of policies.
The mechanism consists of implementing the access matrix and ensuring that
the semantic properties we have outlined hold.

Processes should be able to switch from one domain to another. Switching from

∈access(i,j).Thus,inFigure14.4, a process executing in domain D2 can switch to

domain Di to domain Dj is allowed if and only if the access right switch

domain D3 or to domain D4. A process in domain D4 can switch to D1, and one
in domain D1 can switch to D2.
Access Control
This concept describes how access controls can be used on files within a file
system.
Each file and directory is assigned an owner, a group, or possibly a list of users,
and for each of those entities, access-control information is assigned.
A similar function can be added to other aspects of a computer system.
A good example of this is found in Solaris 10.
Solaris 10 advances the protection available in the operating system by
explicitly adding the principle of least privilege via role-based access control
(RBAC). This facility revolves around privileges.
A privilege is the right to execute a system call or to use an option with in that
system call (such as opening a file with write access).
Privileges can be assigned to processes, limiting them to exactly the access they
need to perform their work.
Privileges and programs can also be assigned to roles.
Users are assigned roles or can take roles based on passwords to the roles.
In this way, a user can take a role that enables a privilege, allowing the user to
run a program to accomplish a specific task, as depicted in Figure.

This implementation of privileges decreases the security risk associated with

superusers and setuid programs.
Revocation of Access Rights
In a dynamic protection system, we may sometimes need to revoke access rights
to objects shared by different users. Various questions about revocation may
arise:
 Immediate versus delayed. Does revocation occur immediately, or is it
delayed? If revocation is delayed, can we find out when it will take place?
 Selective versus general. When an access right to an object is revoked,
does it affect all the users who have an access right to that object, or can
we specify a select group of users whose access rights should be revoked?
 Partial versus total. Can a subset of the rights associated with an object
be revoked, or must we revoke all access rights for this object?
 Temporary versus permanent. Can access be revoked permanently (that
is, the revoked access right will never again be available), or can access
be revoked and later be obtained again?
With an access-list scheme, revocation is easy. The access list is searched for
any access rights to be revoked, and they are deleted from the list.
Revocation is immediate and can be general or selective, total or partial, and
permanent or temporary.
Schemes that implement revocation for capabilities include the following:
 Reacquisition. Periodically, capabilities are deleted from each domain. If
a process wants to use a capability, it may find that that capability has
been deleted. The process may then try to reacquire the capability. If
access has been revoked, the process will not be able to reacquire the
capability.
 Back-pointers. A list of pointers is maintained with each object, pointing
to all capabilities associated with that object. When revocation is
required, we can follow these pointers, changing the capabilities as
necessary. This scheme was adopted in the MULTICS system. It is quite
general, but its implementation is costly.
 Indirection. The capabilities point indirectly, not directly, to the objects.
Each capability points to a unique entry in a global table, which in turn
points to the object. We implement revocation by searching the global
table for the desired entry and deleting it. Then, when an access is
attempted, the capability is found to point to an illegal table entry. Table
entries can be reused for other capabilities without difficulty, since both
the capability and the table entry contain the unique name of the object.
The object for a capability and its table entry must match. This scheme
was adopted in the CAL system. It does not allow selective revocation.
 Keys. A key is a unique bit pattern that can be associated with a
capability. This key is defined when the capability is created, and it can
be neither modified nor inspected by the process that owns the capability.
A master key is associated with each object; it can be defined or replaced
with the set-key operation. When a capability is created, the current value
of the master key is associated with the capability. When the capability is
exercised, its key is compared with the master key. If the keys match, the
operation is allowed to continue; otherwise, an exception condition is
raised. Revocation replaces the master key with a new value via the set-
key operation, invalidating all previous capabilities for this object.