Unit –V

System Protection :Goals of

protection, Principles and domain
protection, Access matrix, Access
control, Revocation of access rights.
Protection:
Introduction:
The processes in an operating system must be
protected from one another’s activities.
To provide such protection, we can use various
mechanisms to ensure that only processes that have
gained proper authorization from the operating system
can operate on the files, memory segments, CPU, and
other resources of a system.
Protection refers to a mechanism for controlling the
access of programs, processes, or users to the
resources defined by a computer system.
Goals of protection:
To prevent malicious misuse of the system by
users or programs.
 To ensure that each shared resource is used
only in accordance with system policies, which
may be set either by system designers or by
system administrators.
 To ensure that errant programs cause the
minimal amount of damage possible.
 protection systems only provide the
mechanisms for enforcing policies and ensuring
reliable systems. It is up to administrators and
users to implement those mechanisms effectively.
Principles of protection
The principle of least privilege dictates that
programs, users, and systems be given just enough
privileges to perform their tasks.
 This ensures that failures do the least amount
of harm and allow the least of harm to be done.
 For example, if a program needs special
privileges to perform a task, it is better to make it
a SGID program with group ownership of
"network" or "backup" or some other pseudo
group, rather than SUID with root ownership. This
limits the amount of damage that can occur if
something goes wrong.
Typically each user is given their own account,
and has only enough privilege to modify their
own files.
 The root account should not be used for
normal day to day activities - The System
Administrator should also have an ordinary
account, and reserve use of the root account for
only those tasks which need the root privileges
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
 Each can be accessed only through well-defined
and meaningful operations.
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.
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.
Domain structure:
Each domain defines a set of objects and the
types of operations that may be invoked on each
object.
The ability to execute an operation on an object
is an access right
A domain is a collection of access rights, each
of which is an ordered pair .
< object-name, rights-set>
For example, if domain D has the access right
<file F,{read , write}>
, then a process executing in domain D can both
read and write file F. It cannot, however,
perform any other operation on that object.
Domains may share access rights.
For example, in Figure 14.1, we have three
domains: D1, D2, and D3.
The access right <O4,{print}>is shared by D2
and D3, implying that a process executing in either
of these two domains can print object O4.
Note that a process must be executing in domain
D1 to read and write object O1, while only
processes in domain D3 may execute object O1.
The association between a process and a domain
may be either static, or dynamic.
Static: If the set of resources available to the
process is fixed throughout the process’s lifetime
is called static.
Dynamic: If the set of resources available to the
process is not fixed throughout the process’s
lifetime is called dynamic.
If the association is dynamic, a mechanism is
available to allow domain switching, enabling
the process to switch from one domain to another.
A domain can be realized in a variety of ways:
1. Each user may be a domain. In this case, the
set of objects that can be accessed depends on the
identity of the user. Domain switching occurs
when the user is changed—generally when one
user logs out and another user logs in.
 2.Each process may be a domain. In this case,
the set of objects that can be accessed depends
on the identity of the process. Domain
switching occurs when one process sends a
message to another process and then waits for a
response.

3 Each procedure may be a domain. In this

case, the set of objects that can be accessed
corresponds to the local variables defined
within the procedure. Domain switching occurs
when a procedure call is made.
An Example: UNIX
UNIX associates domains with users.
 Certain programs operate with the SUID bit set,
which effectively changes the user ID, and
therefore the access domain, while the program is
running. ( and similarly for the SGID bit. )
Unfortunately this has some potential for abuse.
An alternative used on some systems is to place
privileged programs in special directories, so that
they attain the identity of the directory owner when
they run. This prevents crackers from placing SUID
programs in random directories around the system.
Yet another alternative is to not allow the
changing of ID at all. Instead, special privileged
daemons are launched at boot time, and user
processes send messages to these daemons when
they need special tasks performed.
An Example: MULTICS
In the MULTICS system, the protection
domains are organized hierarchically into a ring
structure.
 Each ring corresponds to a single domain
(Figure 14.2). The rings are numbered from 0 to 7
Let Di and Dj be any two domain rings. If j < i,
then Di is a subset of Dj .
That is, a process executing in domain Dj has
more privileges than does a process executing in
domain Di .
 A process executing in domain D0 has the
most privileges. If only two rings exist, this
scheme is equivalent to the monitor–user mode of
execution, where monitor mode corresponds to
D0 and user mode corresponds to D1.
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.
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 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 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).
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.
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)
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 any right in any entry in
column j.
For example, in Figure 14.6(a), 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. Thus, the access matrix of
Figure 14.6(a) can be modified to the access matrix
shown in Figure 14.6(b).
The copy and owner rights allow a process to
change the entries in a column.
A mechanism is also needed to change the
entries in a row. The control right is applicable
only to domain objects.
For example, suppose that, in Figure 14.4, we
include the control right in access(D2, D4). Then,
a process executing in domain D2 could modify
domain D4, as shown in Figure 14.7.
The problem of guaranteeing that no
information initially held in an object can migrate
outside of its execution environment is called the
confinement problem.
Implementation of the Access Matrix
1.Global Table:
The simplest implementation of the access matrix
is a global table consisting of a set of ordered triples.
<domain, object, rights-set>
Whenever an operation M is executed on an object
Oj within domain Di ,the global table is searched for
a triple <Di , Oj , Rk> , with M ∈ Rk .
If this triple is found, the operation is allowed to
Continue.
otherwise, an exception (or error) condition
is raised.
This implementation suffers from several
drawbacks.
The table is usually large and thus cannot be
kept in main memory, so additional I/O is needed.
Virtual memory techniques are often used for
managing this table.
In addition, it is difficult to take advantage of
special groupings of objects or domains.
For example, if everyone can read a particular
object, this object must have a separate entry in
every domain.
Access Lists for Objects:
Each column in the access matrix can be
implemented as an access list for one object,
the empty entries can be discarded.
The resulting list for each object consists of ordered
pairs <domain, rights-set>, which define all domains
with a nonempty set of access rights for that object.
This approach can be extended easily to define a
list plus a default set of access rights. When an
operation M on an object Oj is attempted in domain
Di.
we search the access list for object Oj , looking
for an entry < Di , Rk> with M ∈ Rk .
If the entry is found, we allow the operation; if it
is not, we check the default set. If M is in the
default set, we allow the access.
 Otherwise, access is denied, and an exception
condition occurs. For efficiency, we may check the
default set first and then search the access list.
Capability Lists for Domains:
A capability list for a domain is a list of objects
together with the operations allowed on those objects.
An object is often represented by its physical name
or address, called a capability.
To execute operation M on object Oj , the process
executes the operation M, specifying the capability
(or pointer) for object Oj as a parameter.
Simple possession of the capability means that
access is allowed.
A Lock –Key Mechanism
A Lock –Key Mechanism The lock–key scheme is a
compromise between access lists and capability lists.
Each object has a list of unique bit patterns, called
locks.Similarly, each domain has a list of unique bit
patterns, called keys.
A process executing in a domain can access an
object only if that domain has a key that matches one
of the locks of the object.
As with capability lists, the list of keys for a domain
must be managed by the operating system on behalf of
the domain. Users are not allowed to examine or
modify the list of keys (or locks) directly.
Access control
Role-Based Access Control( RBAC), assigns
privileges to users, programs, or roles as
appropriate, where "privileges" refer to the right to
call certain system calls, or to use certain parameters
with those calls.
 RBAC supports the principle of least privilege,
and reduces the to abuse as opposed to SUID or SGID
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?
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.
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.