UNIT-V

Protection

 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
Operating system consists of a collection of objects, hardware or software . Each
object has a unique name and can be accessed through a well-defined set of
operations.
Protection problem - ensure that each object is accessed correctly and only by
those processes that are allowed to do so.
 Obviously 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.
 Note that protection systems only provide the mechanisms for enforcing
policies and ensuring reliable systems. It is up to administra tors and users to
implement those mechanisms effectively.

Principles of Protection
Programs, users and systems should be given just enough privileges to perform
their tasks
 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 priv
ilege 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 Structure
 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
mod es 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.
 Access-right = <object-name, rights-set>
where rights-set is a subset of all valid operations that can be performed on the object.
Domain = set of access-rights

System consists of 2 domains:

User
Supervisor UNIX
Domain = user-id
Domain switch accomplished via file system
Each file has associated with it a domain bit (setuid bit)
When file is executed and setuid = on, then user -id is set to owner of the
file being executed. When execution completes user-id is reset

Domain Implementation (MULTICS)

Let Di and Dj be any two domain
rings If j < I Þ Di Í Dj

 Rings are numbered from 0 to 7, with outer rings having a subset of the privileges
of the inner rings.
 Each file is a memory segment, and each segment description includes an entry
that indicates the ring number associated with that segment, as well as read, write,
and execute privileges.
 Each process runs in a ring, according to the current-ring-number, a
counter associated with each process.
  A process operating in one ring can only access segments associated with
higher ( farther out ) rings, and then only according to the access bits.
Processes cannot access segments associated with lower rings.
 Domain switching is achieved by a process in one ring calling upon a
process operating in a lower ring, which is controlled by several factors
stored with each segment descriptor:
o An access bracket, defined by integers b1 <= b2.
o A limit b3 > b2
o A list of gates, identifying the entry points at which the segments may
be called.
 If a process operating in ring i calls a segment whose bracket is such that b1
<= i
<= b2, then the call succeeds and the process remains in ring i.
 Otherwise a trap to the OS occurs, and is handled as follows:
o If i < b1, then the call is allowed, because we are transferring to a
procedure with fewer privileges. However if any of the parameters
being passed are of segments below b1, then they must be copied
to an area accessible by the called procedure.
o If i > b2, then the call is allowed only if i <= b3 and the call is
directed to one of the entries on the list of gates.
 Overall this approach is more complex and less efficient than other
protection schemes.
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 doma ins. Entries within the matrix indicate what
access that domain has to that resource.
View protection as a matrix ( access
matrix) Rows represent domains
Columns represent objects
Access (i, j) is the set of operations that a process executing in Domain i can invoke on
Objectj
Use of Access Matrix
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:
Owner of Oi copy op from Oi to Oj
Control – Di can modify Dj access
rights Transfer – switch from
domain Di to Dj
ACCESS MATRIX DESIGN SEPARATES MECHANISM FROM POLICY
Mechanism
 Operating system provides access-matrix + rules
 If ensures that the matrix is only manipulated by authorized agents and
that rules are strictly enforced
Policy
 User dictates policy
 Who can access what object and in what mode
Implementation of Access Matrix
Each column = Access-control list for one
object Defines who can perform what
operation.

Domain 1 = Read,
Write Domain 2 =
Read Domain 3 =
Read

M Each Row = Capability List (like a

key) Fore each domain, what operations allowed on what objects.
Object 1 – Read
Object 4 – Read, Write, Execute
Object 5 – Read, Write, Delete,
Copy
Access Matrix of Figure A With Domains as Objects
Access Matrix with Copy Rights

Access Matrix With Owner Rights

Modified Access Matrix of Figure B

Access Control
Protection can be applied to non-file resources
Solaris 10 provides role-based access control (RBAC) to implement least
privilege Privilege is right to execute system call or use an option within a
system call
Can be assigned to processes
Users assigned roles granting access to privileges and programs
Role-based Access Control in Solaris 10

Revocation of Access Rights

Access List – Delete access rights from access
list Simple
Immediate Capability List – Scheme required to locate capability in the system before
capability can be revoked
Reacquisition
Back-pointers
Indirection
Keys
Capability-Based Systems
Hydra
Fixed set of access rights known to and interpreted by the system
Interpretation of user -defined rights performed solely by user's program; system
provides access protection for use of these rights Ambridge CAP System
Data capability - provides standard read, write, execute of individual storage segments
associated with object
Software capability -interpretation left to the subsystem, through its protected
procedures

Language-Based Protection
Specification of protection in a programming language allows the high -level
description of policies for the allocation and use of resources Language
implementation can provide software for protection enforcement when automatic
hardware -supported checking is unavailable Interpret protection specifications to
generate calls on whatever protection system is provided by the hardware and the
operating system

Protection in Java 2

 Java was designed from the very beginning to operate in a distributed

environment, where code would be executed from a variety of trusted
and untrusted sources. As a result the Java Virtual Machine, JVM
incorporates many protection mechanisms
 When a Java program runs, it load up classes dynamically, in response
to requests to instantiates objects of particular types. These classes may
come from a variety of different sources, some trusted and some not,
which requires that the protection mechanism be implemented at the
resolution of individual classes, something not supported by the basic
operating system.
 As each class is loaded, it is placed into a separate protection domain.
The capabilities of each domain depend upon whether the source URL is
trusted or not, the presence or absence of any digital signatures on the class
( Chapter 15 ), and a configurable policy file indicating which servers a
particular user trusts, etc.
 When a request is made to access a restricted resource in Java, ( e.g. op en a
local file ), some process on the current call stack must specifically assert a
privilege
to perform the operation. In essence this method assumes responsibility for
the restricted access. Naturally the method must be part of a class which resides
in a protection domain that includes the capability for the requested operation.
This approach is termed stack inspection, and works like this:
 o When a caller may not be trusted, a method executes an access
request within a doPrivileged( ) block, which is noted on the
calling stack.
o When access to a protected resource is requested,
checkPermissions( ) inspects the call stack to see if a method has
asserted the privilege to access the protected resource.
 If a suitable doPriveleged block is encountered on the
stack before a domain in which the privilege is disallowed,
then the request is granted.
 If a domain in which the request is disallowed is encountered
first, then the access is denied and a AccessControlException
is thrown.
 If neither is encountered, the n the response is
implementation dependent.
 In the example below the untrusted applet's call to get( ) succeeds, because
the trusted URL loader asserts the privilege of opening the specific URL
lucent.com. However when the applet tries to make a direct ca ll to open(
) it fails, because it does not have privilege to access any sockets.

Stack Inspection