Chapter 14 Protection Mechanisms

Chapter 14: Protection
Goals of Protection
Principles of Protection
Domain of Protection
Access Matrix
Implementation of Access Matrix
Access Control
Revocation of Access Rights
Capability-Based Systems
Language-Based Protection
Operating System Concepts – 7 th Edition
Silberschatz, Galvin and Gagne ©2005 14.2 Modified By Dr. Khaled Wassif

Objectives
Discuss the goals and principles of protection in a
modern computer system.
Explain how protection domains combined with an
access matrix are used to specify the resources a
process may access.
Examine capability and language-based protection
systems.


Goals of Protection
Processes in a system must be protected from
one another's activities.
Protection role is to provide a mechanism for
enforcing the policies governing resource use.
Policies for resource use may vary by application,
and they may change over time.
Therefore, a protection system must have the flexibility
to enforce a variety of policies.
Application programmer needs to use protection
mechanisms as well, to guard resources created
and supported by an application subsystem against
misuse.

Principles of Protection
Guiding principle for protection is the principle of
least privilege:
Programs, users and systems should be given just
enough privileges to perform their tasks.
OS provides mechanisms to enable privileges
when needed and to disable them when they are
not needed.
OS implements its features so that failure or
compromise of a component does minimum damage.
Require creating a separate account for each
user, with just the privileges that the user needs.
Some systems implement role-based access control
(RBAC) rather than user-based.

Domain of Protection
Computer system is a collection of processes and
objects.
Objects include both h/w objects (as CPU, memory
segments, …) and s/w objects (as files, programs, …).
Each object has a unique name and can be
accessed through set of operations well-defined
according to the object type.
A process should be allowed to access only those
resources for which (1) it has authorization (2) required
currently to complete its task – need-to-know principle.
When process p invokes procedure A(), the procedure
should not be able to access all variables of p; just its own
variables and formal parameters passed to it.

Domain Structure
A process operates within a protection domain,
which specifies resources that the process may
access.
Each domain defines a set of objects and types of
operations that may be invoked on each object.
Ability to execute an operation on an object is an
access right.
Access-right = <object-name, rights-set>
where rights-set is a subset of all valid operations that
can be performed on the object.
A protection domain is a collection of access rights.
Domains do not need to be disjoint; they may
share access rights.

System with Three Protection
Domains


Domain Structure (cont.)
Association between a process and a domain may
be either static, if resources available to the process
is fixed throughout process's lifetime, or dynamic.
Establishing dynamic protection domains is more
complicated than establishing static protection domains.
If association between processes and domains is fixed,
then a mechanism to change a domain content must be
available to apply the need-to-know principle.
If association is dynamic, a mechanism is available to
allow domain switching.
A domain can be realized in a variety of ways:
(a) each user, or (b) each process, or (c) each procedure
may be a domain.

Domain Implementation
( UNIX )
Protection domain is associated with the user.
Switching the domain corresponds to changing
the user identification temporarily.
Domain switch accomplished via file system.
An owner ID and a domain bit (known as setuid bit)
are associated with each file.
When the setuid bit is on, and a user executes that
file, the user ID is set to that of the owner of the file.
When the bit is off, however, the user lD does not
change.
When execution completes user-id is reset.

Access Matrix
Protection can be viewed abstractly as a matrix,
called access matrix.
Rows represent domains.
Columns represent objects.
Each entry consists of a set of access rights.
The entry access(i,j) defines set of operations that
a process executing in domain Di can invoke on
object Oj.
Access matrix can implement policy decisions
concerning protection.
Policy decisions involve which rights should be
included in the (i,j)th entry.
Must also decide the domain in which each process
executes – usually decided by OS.

Access Matrix


Use of Access Matrix
Provide an appropriate mechanism for defining
and implementing strict control for static association
between processes and domains.
If a process in domain Di tries to do “op” on object Oj,
then “op” must be in the access matrix.
Can be expanded to dynamic protection.
Operations to add, delete access rights.
Special access rights:
 switch from domain Di to Dj
 copy or transfer op from Di to Dj
 Domain Di owner of object Oj
 control – D can modify Dj access rights
i

Access Matrix with Domains as
Objects
Processes should be able to switch from one
domain to another.
Domain switching from domain Di to domain Dj is
allowed iff the access right switch ∈ access(i,j).


Access Matrix with Copy
Rights
copy right allows
copying access
right from one
domain (row) to
another within the
object (column)
for which the right
is defined.
Denoted by an
asterisk (*)
appended to the
access right.

Access Matrix with Owner
owner right is a
Rights
mechanism to
allow addition
and removal of
some rights.
If access(i,j)
includes owner
right, then a
process running
in domain Di can
add and remove
any right in any
entry in column j.

Access Matrix with Control Rights
control right is a mechanism to change entries in a
row and applicable only to domain objects.
If access(i,j) includes the control right, then a process
running in domain Di can remove any access right from Dj.


Use of Access Matrix (cont.)
copy and owner rights provide a mechanism to
limit propagation of access rights but are not
suitable for preventing propagation of information.
Design of access matrix separates mechanism
from policy.
Mechanism
 Operating system provides access-matrix + rules.
 Itensures that the matrix is only manipulated by authorized
agents and that rules are strictly enforced.
Policy
 User states policy.
 Concerning which domains are to have access to which
objects in which ways.

Implementation of Access
Global Table
Matrix
Simplest implementation of access matrix.
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.
Suffers from several drawbacks
 The table is usually large and cannot be kept in main memory.
 Difficult
to take advantage of special groupings of objects or
domains.

Matrix
Access Lists for Objects
Each column in access matrix is implemented as an
access list for one object.
Resulting list for each object consists of ordered pairs
<domain, rights-set>.
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 :
 Search access list for object Oj, looking for an entry <Di, Rk>,
with M ∈ Rk
 If the entry is found, allow the operation.
 If it is not, check default set and allow the access if M exist in it.
 Otherwise, access is denied and an exception occurs.

Matrix
Capability Lists for Domains
Each row in access matrix is implemented as a
capability list for one domain.
A capability list for a domain is a list of objects together
with the operations allowed on those objects.
A process wanting to execute the operation M on
object Oj must specify the capability (or pointer) for that
object as a parameter.
Each capability list is associated with a domain, but it is
never directly accessible to a process executing in that
domain.
 the capability list is itself a protected object, maintained by the
operating system and accessed by the user only indirectly.

Matrix
A Lock-Key Mechanism
A compromise between access lists and capability lists.
 Each object has a list of unique bit patterns, called locks.
 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
Access-control information is assigned to an owner,
a group, or users list of each file and directory.
Access-control protection can be applied to non-file
resources.
Solaris 10 provides role-based access control
to implement principle of least privilege :
Privilege is the right to execute a system call or use an
option within a system call.
Can be assigned to processes, limiting them to exactly
what are need to perform their work.
Users can take roles granting access to privileges and
running programs.

Role-based Access Control in
Solaris 10


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?
Selective versus general.
 Revoked access right affect all users or a select group of users?
Partial versus total.
 Can revoke a subset of or all rights associated with an object?
Temporary versus permanent.
 Can access revoked permanently or revoked and later obtained
again?

(cont.)
Access List
Revocation is easy
Search and delete access rights from specific
access list.

Immediate
Can be general or selective.
Can be total or partial.
Can be permanent or temporary.

Capability List
(cont.)
Revocation is much more difficult problem.
 Capabilities are distributed throughout the system.
Scheme is required to locate capability in the system
before capability can be revoked.
 Reacquisition
– Periodically, capabilities are deleted from each domain.
 Back-pointers
– List of pointers is maintained with each object, pointing to all
capabilities associated with that object.
 Indirection
– Capabilities point indirectly in a global table, not directly to objects.
 Keys
– Replace the object master key with a new value to invalidating all
previous capabilities (given keys) for this object.

Chapter 14 Protection Mechanisms

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Chapter 14 Protection Mechanisms

Ähnlich wie Chapter 14 Protection Mechanisms (20)

Chapter 14 Protection Mechanisms