Wednesday, November 24, 1993

Protection (chapter 11)
-------------------------------------------------------------------------------
Recall that protection is a mechanism for controlling access to programs and
data stored in a computer system.

Separation of mechanism and policy.  *Protection mechanisms* provide ways of
implementing many different policies governing resource use.  Mechanisms
concerned with *how*, not *what*.
-------------------------------------------------------------------------------
Domain of protection

- computer system collection of processes and objects.
- objects are, e.g., hardware objects (CPU, memory segments, etc.), and
  software objects (e.g., files, programs, semaphores)
- each object has a unique name and well-defined operations (e.g., an
  *abstract data type*.  Operations are object-type-specific
- the ability for a process to execute an operation on an object is
  called *access right*
- *need-to-know* principle: process only able to access those resources
  that it currently requires to complete its task.  (limits damage if
  process is out of control)
- *protection domain*: process operates within a protection domain that
  specifies resources that the process may access
- protection domain defines a set of objects and the types of operations that
  may be executed on each object
- *access right*: ability to execute an operation on an object
- *domain* collection of access rights, each an orderd pair
	<subject-name, rights-set>
  e.g., <file F, {read, write}>, <file G, {read}>, <printer, {print}>
  defines a protection domain
- other examples
	<CPU, {monitor-mode, user-mode}>	Domain D
	<CPU, {user-mode}>			Domain E
  Process in domain D is a system process; one in E is a user process
- Hence domains need not be disjoint (can share access rights)
-------------------------------------------------------------------------------
Access matrix: implementation of protection domain
entry access(i,j) defines set of operations that a process in domain Di
can invoke on object Oj

D1: <O1,{read,write}>, <O2,{execute}>, <O3,{read,write}>
D2: <O2,{write}>, <O4,{print}>
D3: <O1,{execute}>, <O3,{read}>, <O4,{print}>

Access matrix
	O1	O2	O3	O4
D1	read	execute	read
	write		write
D2		write		print
D3	execute		read	print

- want to implement efficiently
- but usually matrix is sparse

- simple implementation: global table of triples <domain, object, rights set>
  problems: large table hence too big for memory (has to be on secondary
      storage either explicitly or via virtual memory. Requires added I/O
    Difficult to take advantage of special groupings of objects---for example
      if an object allows everyone to read it, it must have separate entry in
      every domain

- access list implementation.  Columns in access matrix are implemented as
  an access list, kept by the object (list of <domain, rights-set> pairs)
- easy extension also provides default set of access rights (search local list,
  if operation on object not found check default set)

- each row in the acces smatrix can be implemented as a *capability list*
  kept by the process (<object, access-rights> list)
- simple possession of capability means that specified rights are granted
- manipulation and passing of capabilities has to be implemented by
  OS---capability-based protection assumes that capabilities *never* migrate
  into user space.
-------------------------------------------------------------------------------