UNIT –V
SYSTEM PROTECTION
Goals of Protection
Obviously to prevent malicious misuse of the system by users or programs. See
chapter 15 for a more thorough coverage of this goal.
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.
Note that 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 can be viewed as a collection of processes and objects ( both HW
& SW ).
, The need to know principle states that a process should only have access to
those objects it needs to accomplish its task, and furthermore only in the modes
for which it needs access and only during the time frame when it needs access.
The modes available for a particular object may depend upon its type.
Domain Structure
A protection domain specifies the resources that a process may access.
Each domain defines a set of objects and the types of operations that may be
invoked on each object.
An access right is the ability to execute an operation on an object.
A domain is defined as a set of < object, { access right set } > pairs, as shown
below. Note that some domains may be disjoint while others overlap.
Figure 14.1 - System with three protection domains.
The association between a process and a domain may be static or dynamic.
o If the association is static, then the need-to-know principle requires a
way of changing the contents of the domain dynamically.
o If the association is dynamic, then there needs to be a mechanism
for domain switching.
Domains may be realized in different fashions - as users, or as processes, or as
procedures. E.g. if each user corresponds to a domain, then that domain
defines the access of that user, and changing domains involves changing user
ID.
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.
Access Matrix
The model of protection that we have been discussing can be viewed as
an access matrix, in which columns represent different system resources and
rows represent different protection domains. Entries within the matrix indicate
what access that domain has to that resource.
.
Figure 14.3 - Access matrix.
Domain switching can be easily supported under this model, simply by
providing "switch" access to other domains:
, Figure 14.4 - Access matrix of Figure 14.3 with domains as objects.
The ability to copy rights is denoted by an asterisk, indicating that processes in
that domain have the right to copy that access within the same column, i.e. for
the same object. There are two important variations:
o If the asterisk is removed from the original access right, then the right
is transferred, rather than being copied. This may be termed
a transfer right as opposed to a copy right.
o If only the right and not the asterisk is copied, then the access right is
added to the new domain, but it may not be propagated further. That is
the new domain does not also receive the right to copy the access. This
may be termed a limited copy right, as shown in Figure 14.5 below:
SYSTEM PROTECTION
Goals of Protection
Obviously to prevent malicious misuse of the system by users or programs. See
chapter 15 for a more thorough coverage of this goal.
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.
Note that 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 can be viewed as a collection of processes and objects ( both HW
& SW ).
, The need to know principle states that a process should only have access to
those objects it needs to accomplish its task, and furthermore only in the modes
for which it needs access and only during the time frame when it needs access.
The modes available for a particular object may depend upon its type.
Domain Structure
A protection domain specifies the resources that a process may access.
Each domain defines a set of objects and the types of operations that may be
invoked on each object.
An access right is the ability to execute an operation on an object.
A domain is defined as a set of < object, { access right set } > pairs, as shown
below. Note that some domains may be disjoint while others overlap.
Figure 14.1 - System with three protection domains.
The association between a process and a domain may be static or dynamic.
o If the association is static, then the need-to-know principle requires a
way of changing the contents of the domain dynamically.
o If the association is dynamic, then there needs to be a mechanism
for domain switching.
Domains may be realized in different fashions - as users, or as processes, or as
procedures. E.g. if each user corresponds to a domain, then that domain
defines the access of that user, and changing domains involves changing user
ID.
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.
Access Matrix
The model of protection that we have been discussing can be viewed as
an access matrix, in which columns represent different system resources and
rows represent different protection domains. Entries within the matrix indicate
what access that domain has to that resource.
.
Figure 14.3 - Access matrix.
Domain switching can be easily supported under this model, simply by
providing "switch" access to other domains:
, Figure 14.4 - Access matrix of Figure 14.3 with domains as objects.
The ability to copy rights is denoted by an asterisk, indicating that processes in
that domain have the right to copy that access within the same column, i.e. for
the same object. There are two important variations:
o If the asterisk is removed from the original access right, then the right
is transferred, rather than being copied. This may be termed
a transfer right as opposed to a copy right.
o If only the right and not the asterisk is copied, then the access right is
added to the new domain, but it may not be propagated further. That is
the new domain does not also receive the right to copy the access. This
may be termed a limited copy right, as shown in Figure 14.5 below:
