Protection

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. Of more general importance, however, is the need to ensure
that each program component active in a system uses system resources only in ways
consistent with stated policies. This requirement is an absolute one for a reliable system.
Protection can improve reliability by detecting latent errors at the interfaces between
component subsystems. Early detection of interface errors can often prevent contamination of
a healthy subsystem by a malfunctioning subsystem. Also, an unprotected resource cannot
defend against use (or misuse) by an unauthorized or incompetent user. A protection-oriented
system provides means to distinguish between authorized and unauthorized usage. 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. Still others are defined by the individual users to protect their own files and
programs. A protection system must have the flexibility to enforce a variety of policies.
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. In this chapter, we
describe the protection mechanisms the operating system should provide, but application
designers can use them as well in designing their own protection software. Note that
mechanisms are distinct from policies. Mechanisms determine how something will be done;
policies decide what will be done. The separation of policy and mechanism is important for
flexibility. Policies are likely to change from place to place or time to time. In the worst case,
every change in policy would require a change in the underlying mechanism. Using general
mechanisms enables us to avoid such a situation.

Principles of protection

Frequently, a guiding principle can be used throughout a project, such as the design of an
operating system. Following this principle simplifies design decisions and keeps the system
consistent and easy to understand. A key, time-tested guiding principle for protection is the
principle of least privilege. It dictates that programs, users, and even systems be given just
enough privileges to perform their tasks. Consider the analogy of a security guard with a
passkey. If this key allows the guard into just the public areas that she guards, then misuse of
the key will result in minimal damage. If, however, the passkey allows access to all areas,
then damage from its being lost, stolen, misused, copied, or otherwise compromised will be
much greater. An operating system following the principle of least privilege implements its
features, programs, system calls, and data structures so that failure or compromise of a
component does the minimum damage and allows the minimum damage to be done. The
overflow of a buffer in a system daemon might cause the daemon process to fail, for example,
but should not allow the execution of code from the daemon process’s stack that would
enable a remote user to gain maximum privileges and access to the entire system (as happens
too often today). Such an operating system also provides system calls and services that allow
applications to be written with fine-grained access controls. It provides mechanisms to enable
privileges when they are needed and to disable them when they are not needed. Also
beneficial is the creation of audit trails for all privileged function access. The audit trail
allows the programmer, system administrator, or law-enforcement officer to trace all
protection and security activities on the system. Managing users with the principle of least
privilege entails creating a separate account for each user, with just the privileges that the
user needs. An operator who needs to mount tapes and back up files on the system has access
to just those commands and files needed to accomplish the job. Some systems implement
role-based access control (RBAC) to provide this functionality. Computers implemented in a
computing facility under the principle of least privilege can be limited to running specific
services, accessing specific remote hosts via specific services, and doing so during specific
times. Typically, these restrictions are implemented through enabling or disabling each
service and through using access control lists. The principle of least privilege can help
produce a more secure computing environment. Unfortunately, it frequently does not. For
example, Windows 2000 has a complex protection scheme at its core and yet has many
security holes. By comparison, Solaris is considered relatively secure, even though it is a
variant of UNIX, which historically was designed with little protection in mind. One reason
for the difference may be that Windows 2000 has more lines of code and more services than
Solaris and thus has more to secure and protect. Another reason could be that the protection
scheme in Windows 2000 is incomplete or protects the wrong aspects of the operating
system, leaving other areas vulnerable.

Domain of protection

A computer system is a collection of processes and objects. By objects, we mean both

hardware objects (such as the CPU, memory segments, printers, disks, and tape drives) and
software objects (such as files, programs, and semaphores). Each object has a unique name
that differentiates it from all other objects in the system, and each can be accessed only
through well-defined and meaningful operations. Objects are essentially abstract data types.
The operations that are possible may depend on the object. For example, on a CPU, we can
only execute. Memory segments can be read and written, whereas a CD-ROM or DVD-ROM
can only be read. Tape drives can be read, written, and rewound. Data files can be created,
opened, read, written, closed, and deleted; program files can be read, written, executed, and
deleted. A process should be allowed to access only those resources for which it has
authorization. Furthermore, at any time, a process should be able to access only those
resources that it currently requires to complete its task. This second requirement, commonly
referred to as the need-to-know principle, is useful in limiting the amount of damage a faulty
process can cause in the system. For example, when process p invokes procedure A(), the
procedure should be allowed to access only its own variables and the formal parameters
passed to it; it should not be able to access all the variables of process p. Similarly, consider
the case in which process p invokes a compiler to compile a particular file. The compiler
should not be able to access files arbitrarily but should have access only to a well-defined
subset of files (such as the source file, listing file, and so on) related to the file to be
compiled. Conversely, the compiler may have private files used for accounting or
optimization purposes that process p should not be able to access. The need-to-know
principle is similar to the principle of least privilege discussed in Section 14.2 in that the
goals of protection are to minimize the risks of possible security violations.

Access matrix

Our general model of 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 . To illustrate
these concepts, we consider the access matrix shown in Figure 14.3. 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

Figure 14.3 Access Matrix

domain D1; but in addition, it can also write onto files F1 and F3. The laser 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. More specifically, we must ensure that a process executing in domain Di can access
only those objects specified in row i, and then only as allowed by the access-matrix entries.
The access matrix can implement policy decisions concerning protection. The policy
decisions involve which rights should be included in the (i,j)th entry. We must also decide the
domain in which each process executes. This last policy is usually decided by the operating
system. The users normally decide the contents of the access-matrix entries. When a user
creates a new object Oj , the column Oj is added to the access matrix with the appropriate
initialization entries, as dictated by the creator. The user may decide to enter some rights in
some entries in column j and other rights in other entries, as needed. The access matrix
provides an appropriate mechanism for defining and implementing strict control for both
static and dynamic association between processes and domains. When we switch a process
from one domain to another, we are executing an operation (switch) on an object (the
domain). We can control domain switching by including domains among the objects of the
access matrix. Similarly, when we change the content of the access matrix, we are performing
an operation on an object: the access matrix. Again, we can control these changes by
including the access matrix itself as an object. Actually, since each entry in the access matrix
can be modified individually, we must consider each entry in the access matrix as an object to
be protected. Now, we need to consider only the operations possible on these new objects
(domains and the access matrix) and decide how we want processes to be able to execute
these operations. Processes should be able to switch from one domain to another. Switching
from domain Di to domain Dj is allowed if and only if the access right switch ∈ access(i, j).
Thus, in Figure 14.4, a process executing in domain D2 can switch

to domain D3 or to domain D4. A process in domain D4 can switch to D1, and one in domain
D1 can switch to D2. Allowing controlled change in the contents of the access-matrix entries
requires three additional operations: copy, owner, and control. We examine these operations
next. The ability to copy an access right from one domain (or row) of the access matrix to
another is denoted by an asterisk (*) appended to the access right. The copy right allows the
access right to be copied only within the column (that is, for the object) for which the right is
defined. For example, in Figure 14.5(a), a process executing in domain D2 can copy the read
operation into any entry associated with file F2. Hence, the access matrix of Figure 14.5(a)
can be modified to the access matrix shown in Figure 14.5(b). This scheme has two
additional variants: 1. A right is copied from access(i, j) to access(k, j); it is then removed
from access(i, j). This action is a of a right, rather than a copy. 2. Propagation of the copy
right may be limited. That is, when the right R∗ is copied from access(i, j) to access(k, j),
only the right R (not R∗) is created. A process executing in domain Dk cannot further copy
the right R. A system may select only one of these three copy rights, or it may provide all
three by identifying them as separate rights: copy, transfer, and limited copy. We also need a
mechanism to allow addition of new rights and removal of some rights. The owner right
controls these operations. If access(i, j) includes the owner right, then a process executing in
domain Di can add and remove

Figure 14.5 (a) & (b)

any right in any entry in column j. For example, in Figure 14.6, domain D1 is the owner of F1
and thus can add and delete any valid right in column F1. Similarly, domain D2 is the owner
of F2 and F3 and thus can add and remove any valid right within these two columns.
 Figure 14.6 Access Matrix

Implementation of access matrix

How can the access matrix be implemented effectively? In general, the matrix will be sparse;
that is, most of the entries will be empty. Although data structure techniques are available for
representing sparse matrices, they are not particularly useful for this application, because of
the way in which the protection facility is used. Here, we first describe several methods of
implementing the access matrix and then compare the methods.

 Global Trade
 Access list for objects
 Capability list for domains
 A Lock- key mechanism
 Comparison

Access Control

We described 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 within 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 14.8. 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. Capabilities,
however, present a much more difficult revocation problem, as mentioned earlier. Since the
capabilities are distributed throughout the system, we must find them before we can revoke
them. 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 14.8 Capability-Based Systems 641
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. This
scheme does not allow selective revocation, since only one master key is associated with each
object. If we associate a list of keys with each object, then selective revocation can be
implemented. Finally, we can group all keys into one global table of keys. A capability is
valid only if its key matches some key in the global table. We implement revocation by
removing the matching key from the table. With this scheme, a key can be associated with
several objects, and several keys can be associated with each object, providing maximum
flexibility. In key-based schemes, the operations of defining keys, inserting them into lists,
and deleting them from lists should not be available to all users. In particular, it would be
reasonable to allow only the owner of an object to set the keys for that object. This choice,
however, is a policy decision that the protection system can implement but should not define.
System Protection in Operating System
Protection refers to a mechanism which controls the access of programs,
processes, or users to the resources defined by a computer system. We can take
protection as a helper to multi programming operating system, so that many users
might safely share a common logical name space such as directory or files.
Need of Protection:
 To prevent the access of unauthorized users and
 To ensure that each active programs or processes in the system uses
resources only as the stated policy,
 To improve reliability by detecting latent errors.
Role of Protection:
The role of protection is to provide a mechanism that implement policies which
defines the uses of resources in the computer system. Some policies are defined at
the time of design of the system, some are designed by management of the system
and some are defined by the users of the system to protect their own files and
programs.
Every application has different policies for use of the resources and they may
change over time so protection of the system is not only concern of the designer of
the operating system. Application programmer should also design the protection
mechanism to protect their system against misuse.
Policy is different from mechanism. Mechanisms determine how something will be
done and policies determine what will be done. Policies are changed over time and
place to place. Separation of mechanism and policy is important for the flexibility of
the system.
• Guiding Principle – Principle of Least Privilege

• Programs, users and systems should be given just enough privileges to perform their
tasks

• Limits damage if entity has a bug.

• Can be static (during life of system, during life of process)

• Can be dynamic (changed by process as needed) – domain switching, privilege

escalation

• “Need to know” a similar concept regarding access to data

• Must consider “grain” aspect

• Rough-grained privilege management easier, simpler, but least privilege now done
in large chunks

• Fine-grained management more complex, more overhead, but more protective

• Domain can be user, process, procedure

Access matrix in Operating System
Access Matrix is a security model of protection state in computer system. It is
represented as a matrix. Access matrix is used to define the rights of each process
executing in the domain with respect to each object. The rows of matrix represent
domains and columns represent objects. Each cell of matrix represents set of access
rights which are given to the processes of domain means each entry(i, j) defines the
set of operations that a process executing in domain Di can invoke on object Oj.
F1 F2 F3 PRINTER

D1 Read read

D2 print

D3 read execute

D4 read write read write

According to the above matrix: there are four domains and four objects- three
files(F1, F2, F3) and one printer. A process executing in D1 can read files F1 and F3.
A process executing in domain D4 has same rights as D1 but it can also write on
files. Printer can be accessed by only one process executing in domain D2. The
mechanism of access matrix consists of many policies and semantic properties.
Specifically, We must ensure that a process executing in domain Di can access only
those objects that are specified in row i.
Policies of access matrix concerning protection involve which rights should be
included in the (i, j)th entry. We must also decide the domain in which each process
executes. This policy is usually decided by the operating system. The Users decide
the contents of the access-matrix entries.
Association between the domain and processes can be either static or dynamic.
Access matrix provides an mechanism for defining the control for this association
between domain and processes. When we switch a process from one domain to
another, we execute a switch operation on an object(the domain). We can control
domain switching by including domains among the objects of the access matrix.
Processes should be able to switch from one domain (Di) to another domain (Dj) if
and only is a switch right is given to access(i, j).

F1 F2 F3 PRINTER D1 D2 D3 D4

D1 read read switc

 F1 F2 F3 PRINTER D1 D2 D3 D4

D2 print switch switch

D3 read execute

read read

D4 write write switch

According to the matrix: a process executing in domain D2 can switch to domain D3

and D4. A process executing in domain D4 can switch to domain D1 and process
executing in domain D1 can switch to domain D2.

Implementation of Access Matrix in Distributed

OS
As earlier discussed as access matrix is likely to be very sparse and takes up a large chunk of
memory. Therefore, direct implementation of access matrix for access control is storage
inefficient.
The inefficiency can be removed by decomposing the access matrix into rows or columns.
Rows can be collapsed by deleting null values and so for the columns to increase efficiency.
From these approaches of decomposition three implementation of access matrix can be
formed which are widely used. They are as follows:
1. Capabilities
2. Access Control List
3. Lock and Key Method
So we are going to discuss in brief about the above implementation.
Its worth remembering that we are denoting subjects by s and objects by O and putting them
on columns and rows respectively.
1. Capabilities:
This method refers to row wise decomposition of the access matrix. Each
Subject is assigned with a list of tuples (o, M[s, o]) for all objects o that it
is allowed to access. These tuples are called Capabilities. If a subject
possess a capability (o, M[s, o]) then it is allowed to access object o in
the manner which is described in M[s, o]. A subject is allowed to access
any objects for which it holds the capabilities. Capabilities are not meant
to be forged.
Capabilities contain two fields:

1.
(i) Object Descriptor,
2. (ii) Access Rights
 Object Descriptor may contain the address of the objects and Access
Rights may contain the rights which the subject has on object, mainly
read write, execute. Since object Descriptor contains address it may be
used as an addressing mechanism also.
Below is the format of capability.

3. Access Control List:

This method refers to column wise decomposition of the access matrix .
Each object o has a list containing tuples like (s, M[s, o]) for all subjects s
which can access the object.P[s, o] denotes the rights of the subject s on
the object o.
when a subject s request to access to the object o it is executed in the
following manner.
 The system searches the access control list of o to find out if
an entry (s, ) exist for subject s
 If and entry (s, ) exists for subject s then the system
checks to see if the requested access is permitted or not.
(i.e., )
 If the requested access is permitted then the request is
executed else an appropriate exception is raised.
Below is a sample implementation of Access Control List of an object o.
;

SUBJECTS ACCESS RIGHT

ravi Read, Write, Execute

rana Read

jeffy Write

alice Execute

Easy revocation and Easy review of an access are the major feature
of access control list.
4. Lock and key Method:
The lock and key method is an hybrid of the access control list and
capabilities method.
In the lock and key method, every subject has a capability list that
contains tuples of the form (o, key), indicating the subject can access
object o using key key. Objects has an access control list that contains
tuples of the form (lock, ), called a lock entry indicating lock lock can
be accessed by modes in the set .
When the subject makes the request to access object o in mode , the
system executes in the following manner.
 The system locates the tuple (o, key) in the capability list of
the subject. If no such tuple id found, the access is not
permitted.
 Otherwise the access is permitted only if there exists a lock
entry (lock, ) in the access control list of object o such
that key=lock