ch14 protection use in operating sys.ppt

Silberschatz, Galvin and Gagne ©2013
Operating System Concepts – 9th
Edition
Chapter 14: Protection

14.2 Silberschatz, Galvin and Gagne ©2013
Edition
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

Edition
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

Edition
 The processes in an operating system must be protected
from one another’s activities.
 Protection refers to a mechanism for controlling the
access of programs, processes, or users to the
resources defined by a computer system.

Edition
Goals of Protection
 In one protection model, computer 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

Edition
Principles of Protection
 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, gets abused
 Can be static (during life of system, during life of
process)
 Or dynamic (changed by process as needed) –
domain switching, privilege escalation
 “Need to know” a similar concept regarding access to
data

Edition
Domain of Protection
 Acomputer system is a collection of processes and objects.
 By objects, we mean both
hardware objects (CPU, memory segments, printers,
disks,and tape drives)
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.
 The operations that are possible may depend on the object.

Edition
For example,
 a CPU, we can only execute.
 Memory segments can be read and written,
 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.

Edition
 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.

Edition
Domain Structure
 A process operates within a protection domain, which specifies the
resources that the process may access.
 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.

Edition
 If the association is dynamic, a mechanism is available
to allow domain switching, enabling the process to
switch from one domain to other.
 We may also want to allow the content of a domain to be
changed.
 A domain can be realized in a variety ofways:
 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.

Edition
 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 response.
 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.

Edition
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 .

Edition
Access Matrix
 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 Domaini can invoke on Objectj

Edition
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
 User who creates object can define access column for that
object
 Can be expanded to dynamic protection
 Operations to add, delete access rights
 Special access rights:
 owner of Oi
 copy op from Oi to Oj (denoted by “*”)
 control – Di can modify Dj access rights
 transfer – switch from domain Di to Dj
 Copy and Owner applicable to an object
 Control applicable to domain object

Edition
Use of Access Matrix (Cont.)
 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
 But doesn’t solve the general confinement problem

Edition
Access Matrix of Figure A with Domains as Objects

Edition
Access Matrix with Copy Rights

Edition
Access Matrix With Owner Rights

Edition
Modified Access Matrix of Figure B

Edition
Implementation of Access Matrix
Global Table
 The simplest approach is one big global table with
< domain, object, rights > entries.
 Unfortunately this table is very large ( even if sparse ) and so cannot
be kept in memory ( without invoking virtual memory techniques. )
 There is also no good way to specify groupings - If everyone has
access to some resource, then it still needs a separate entry for
every domain.

Edition
Implementation of Access Matrix (Cont.)
Access Lists for Objects
 Each column of the table can be kept
as a list of the access rights for that
particular object, discarding blank
entries.
 For efficiency a separate list of
default access rights can also be
kept, and checked first.

Edition
 Each column = Access-control list for one object
Defines who can perform what operation
Domain 1 = Read, Write
Domain 2 = Read
Domain 3 = Read
 Each Row = Capability List (like a key)
For each domain, what operations allowed on what objects
Object F1 – Read
Object F4 – Read, Write, Execute
Object F5 – Read, Write, Delete, Copy

Edition
Capability Lists for Domains
 In a similar fashion, each row of the table can be kept as a list of the
capabilities of that domain.
 Capability lists are associated with each domain, but not directly
accessible by the domain or any user process.
 .
 Option 3 – Capability list for domains
 Instead of object-based, list is domain based
 Capability list for domain is list of objects together with operations allows on them
 Object represented by its name or address, called a capability
 Execute operation M on object Oj, process requests operation and specifies capability as parameter
 Possession of capability means access is allowed
 Capability list associated with domain but never directly accessible by domain
 Rather, protected object, maintained by OS and accessed indirectly
 Like a “secure pointer”
 Idea can be extended up to applications

Edition
 Capability lists are themselves protected
resources, distinguished from other data in one
of two ways:
 A tag, possibly hardware implemented, distinguishing
this special type of data. ( other types may be floats,
pointers, booleans, etc. )
 The address space for a program may be split into
multiple segments, at least one of which is
inaccessible by the program itself, and used by the
operating system for maintaining the process's access
right capability list

Edition
A Lock-Key Mechanism
 Each resource has a list of unique bit patterns, termed
locks.
 Each domain has its own list of unique bit patterns,
termed keys.
 Access is granted if one of the domain's keys fits one of
the resource's locks.
 Again, a process is not allowed to modify its own keys.

Edition
Comparison of Implementations
 Many trade-offs to consider
 Global table is simple, but can be large
 Access lists correspond to needs of users
Determining set of access rights for domain non-localized so
difficult
Every access to an object must be checked
– Many objects and access rights -> slow
 Capability lists useful for localizing information for a given process
But revocation capabilities can be inefficient
 Lock-key effective and flexible, keys can be passed freely from
domain to domain, easy revocation

Edition
Comparison of Implementations (Cont.)
 Most systems use combination of access lists and
capabilities
 First access to an object -> access list searched
 If allowed, capability created and attached to
process
– Additional accesses need not be checked
 After last access, capability destroyed
 Consider file system with ACLs per file

Edition
Access Control
 Protection can be applied to non-file
resources
 Oracle 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
 Enable role via password to
gain its privileges
 Similar to access matrix

Edition
Revocation of Access Rights
 Various options to remove the access right of a domain to an
object
 Immediate vs. delayed
 Selective vs. general
 Partial vs. total
 Temporary vs. permanent
 Access List – Delete access rights from access list
 Simple – search access list and remove entry
 Immediate, general or selective, total or partial,
permanent or temporary

Edition
Revocation of Access Rights (Cont.)
 Capability List – Scheme required to locate capability in the system
before capability can be revoked
 Reacquisition – periodic delete, with require and denial if revoked
 Back-pointers – set of pointers from each object to all capabilities
of that object (Multics)
 Indirection – capability points to global table entry which points to
object – delete entry from global table, not selective (CAL)
 Keys – unique bits associated with capability, generated when
capability created
 Master key associated with object, key matches master key for
access
 Revocation – create new master key
 Policy decision of who can create and modify keys – object
owner or others?

Edition
Capability-Based Systems
 Hydra
 Fixed set of access rights known to and interpreted by the system
 i.e. read, write, or execute each memory segment
 User can declare other auxiliary rights and register those with
protection system
 Accessing process must hold capability and know name of
operation
 Rights amplification allowed by trustworthy procedures for a
specific type
 Interpretation of user-defined rights performed solely by user's
program; system provides access protection for use of these rights
 Operations on objects defined procedurally – procedures are
objects accessed indirectly by capabilities
 Solves the problem of mutually suspicious subsystems
 Includes library of prewritten security routines

Edition
Capability-Based Systems (Cont.)
 Cambridge CAP System
 Simpler but powerful
 Data capability - provides standard read, write, execute
of individual storage segments associated with object –
implemented in microcode
 Software capability -interpretation left to the
subsystem, through its protected procedures
 Only has access to its own subsystem
 Programmers must learn principles and techniques
of protection

Edition
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

Edition
Protection in Java 2
 Protection is handled by the Java Virtual Machine (JVM)
 A class is assigned a protection domain when it is loaded by
the JVM
 The protection domain indicates what operations the class
can (and cannot) perform
 If a library method is invoked that performs a privileged
operation, the stack is inspected to ensure the operation can
be performed by the library
 Generally, Java’s load-time and run-time checks enforce type
safety
 Classes effectively encapsulate and protect data and
methods from other classes

Edition
Stack Inspection

ch14 protection use in operating sys.ppt

More Related Content

Similar to ch14 protection use in operating sys.ppt (20)

More from vvsp1 (8)

Recently uploaded (20)

ch14 protection use in operating sys.ppt