Chapter 14: System Protection (3721)

Chapter 14: System Protection (3721)

1. Protection refers to a mechanism for controlling the access of programs, processes, or users to the resources defined by a computer system.

2. 14.1 Goals of Protection

   • We need to provide protection for several reasons
     • need to prevent the mischievous, intentional violation of an access restriction by a user
     • the need to ensure that each program component active in a system uses system resources only in ways consistent with stated policies
     • Protection can improve reliability by detecting latent errors at the interfaces between component subsystems
   • Note that mechanisms are distinct from policies. Mechanisms determine how something will be done; policies decide what will be done.
   • The role of protection in a computer system is to provide a mechanism for the enforcement of the policies governing resource use

3. mechanism must provide a means for specifying the controls to be imposed, together with a means of enforcement.

4. 14.2 Principles of Protection

   • A key, time-tested guiding principle for protection is the principle of least privilege
   • dictates that programs, users, and even systems be given just enough privileges to perform their tasks.
   • Managing users with the principle of least privilege entails creating a separate account for each user, with just the privileges that the user needs.
   • The principle of least privilege can help produce a more secure computing environment.

5. 14.3 Domain of Protection

   • A computer system is a collection of processes and objects.
     • hardware objects (such as the CPU, memory segments, printers, disks, and tape drives) and software objects (such as files, programs, and semaphores).
   • A process should be allowed to access only those resources for which it has authorization
   • need-to-know principle, is useful in limiting the amount of damage a faulty process can cause in the system.
   • 14.3.1 Domain Structure
     • To facilitate the scheme just described, a process operates within a protection domain, which specifies the resources that the process may access.
     • A domain is a collection of access rights, each of which is an ordered pair <object-name, rights-set>
     • Domains may share access rights.
     • The association between a process and a domain may be either static, if the set of resources available to the process is fixed throughout the process’s lifetime, or dynamic.
       • then a mechanism must be available to change the content of a domain.
       • If the association is dynamic, a mechanism is available to allow domain switching, enabling the process to switch from one domain to another.
     • If the association is dynamic, a mechanism is available to allow domain switching, enabling the process to switch from one domain to another.
       • • 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 happens when a user logs out and another logs in
       • • 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 a response.
       • • Each procedure may be a domain
         • 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.
     • Consider the standard dual-mode (monitor–user mode) model of operating-system execution.
       • monitor mode, it can execute privileged instructions and thus gain complete control of the computer system.
       • user mode, it can invoke only nonprivileged instructions, in its memory space
       • These two modes protect the operating system (executing in monitor domain) from the user processes (executing in user domain).
   • 14.3.2 An Example: UNIX
   • 14.3.3 An Example: MULTICS
     • In the MULTICS system, the protection domains are organized hierarchically into a ring structure.
     • The rings are numbered from 0 to 7. Let Di and Dj be any two domain rings. If j < i, then Di is a subset of Dj
     • a process executing in domain Dj has more privileges than does a process executing in domain Di
     • If only two rings exist, this scheme is equivalent to the monitor–user mode of execution,
     • MULTICS has a segmented address space; each segment is a file, and each segment is associated with one of the rings.
     • A segment description includes an entry that identifies the ring number
       • it includes three access bits to control reading, writing, and execution.
     • A current-ring-number counter is associated with each process, identifying the ring in which the process is executing currently
     • When a process is executing in ring i, it cannot access a segment associated with ring j (j < i). It can access a segment associated with ring k (k ≥ i). The type of access, however, is restricted according to the access bits associated with that segment.
     • Domain switching in MULTICS occurs when a process crosses from one ring to another by calling a procedure in a different ring.
     • To allow controlled domain switching, we modify the ring field of the segment descriptor to include the following:
       • • Access bracket. A pair of integers, b1 and b2, such that b1 ≤ b2.
       • • Limit. An integer b3 such that b3 > b2.
       • • List of gates. Identifies the entry points (or gates) at which the segments may be called.
     • The main disadvantage of the ring (or hierarchical) structure is that it does not allow us to enforce the need-to-know principle.
       • In particular, if an object must be accessible in domain Dj but not accessible in domain Di, then we must have j < i. But this requirement means that every segment accessible in Di is also accessible in Dj.
     • If a process executing in ring i calls a procedure (or segment) with access bracket (b1,b2), then the call is allowed if b1 ≤ i ≤ b2, and the current ring number of the process remains i. Otherwise, a trap to the operating system occurs, and the situation is handled as follows:
       • • If i < b1, then the call is allowed to occur, because we have a transfer to a ring (or domain) with fewer privileges. However, if parameters are passed that refer to segments in a lower ring (that is, segments not accessible to the called procedure), then these segments must be copied into an area that can be accessed by the called procedure
       • • If i > b2, then the call is allowed to occur only if b3 is greater than or equal to i and the call has been directed to one of the designated entry points in the list of gates. This scheme allows processes with limited access rights to call procedures in lower rings that have more access rights, but only in a carefully controlled manner.
     • To separate mechanism from policy, we require a more general model of protection.

6. 14.4 Access Matrix

   • Our general model of protection can be viewed abstractly as a matrix, called an access matrix
   • A process executing in domain D1 can read object F1 and F3.
   • The policy decisions involve which rights should be included in the (i, j)th entry.
   • When we switch a process from one domain to another, we are executing an operation (switch) on an object (the domain).
   • Allowing controlled change in the contents of the access-matrix entries requires three additional operations: copy, owner, and control
   • The ability to copy an access right from one domain (or row) of the access matrix to another is denoted by an asterisk (*) appended to the access right.
   • The copy right allows the access right to be copied only within the column (that is, for the object) for which the right is defined
     • 1. A right is copied from access(i, j) to access(k, j); it is then removed from access(i, j). This action is a transfer of a right, rather than a copy.
     • 2. Propagation of the copy right may be limited. That is, when the right R∗ is copied from access(i, j) to access(k, j), only the right R (not R∗) is created. A process executing in domain Dk cannot further copy the right R. (without grant)
   • The owner right controls the operations for the addition of new rights and removal of some rights.
     • domain D1 is the owner of F1 and thus can add and delete any valid right in column F1.
   • The copy and owner rights allow a process to change the entries in a column
   • The control right is applicable only to domain objects.
     • If access(i, j) includes the control right, then a process executing in domain Di can remove any access right from row j.
   • The problem of guaranteeing that no information initially held in an object can migrate outside of its execution environment is called the confinement problem.
     • The copy and owner rights provide us with a mechanism to limit the propagation of access rights. However, they do not give us the appropriate tools for preventing the propagation (or disclosure) of information.
     • unsolvable

7. 14.5 Implementation of the Access Matrix

   • 14.5.1 Global Table
     • The simplest implementation of the access matrix is a global table 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.
     • The table is usually large and thus cannot be kept in main memory, so additional I/O is needed.
     • Virtual memory techniques are often used for managing this table
     • if everyone can read a particular object, this object must have a separate entry in every domain.
   • the matrix will be sparse; that is, most of the entries will be empty.
   • 14.5.2 Access Lists for Objects
     • Each column in the access matrix can be implemented as an access list for one object
     • The resulting list for each object consists of ordered pairs <domain, rights-set>
   • 14.5.3 Capability Lists for Domains
     • Rather than associating the columns of the access matrix with the objects as access lists, we can associate each row with its domain
     • A capability list for a domain is a list of objects together with the operations allowed on those objects
     • An object is often represented by its physical name or address, called a capability. To execute operation M on object Oj, the process executes the operation M, specifying the capability (or pointer) for object Oj as a parameter. Simple possession of the capability means that access is allowed.
     • The capability list is associated with a domain, but it is never directly accessible to a process executing in that domain.
     • capability list is itself a protected object, maintained by the operating system and accessed by the user only indirectly.
     • Capabilities are usually distinguished from other data in one of two ways:
       • • Each object has a tag to denote whether it is a capability or accessible data
         • Thus, the hardware can distinguish integers, floating-point numbers, pointers, Booleans, characters, instructions, capabilities, and uninitialized values by their tag
       • • Alternatively, the address space associated with a program can be split into two parts. One part is accessible to the program and contains the program’s normal data and instructions. The other part, containing the capability list, is accessible only by the operating system. A segmented memory space (Section 8.4) is useful to support this approach.
   • 14.5.4 A Lock–Key Mechanism
     • The lock–key scheme is a compromise between access lists and capability lists.
     • Each object has a list of unique bit patterns, called locks. Similarly, 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.
     • 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.
   • 14.5.5 Comparison
     • Using a global table is simple; however, the table can be quite large and often cannot take advantage of special groupings of objects or domains.
     • Access lists correspond directly to the needs of users. When a user creates an object, he can specify which domains can access the object, as well as what operations are allowed
     • Capability lists do not correspond directly to the needs of users, but they are useful for localizing information for a given process. The process attempting access must present a capability for that access. Then, the protection system needs only to verify that the capability is valid. Revocation of capabilities, however, may be inefficient (Section 14.7)
     • The lock and key mechanism. The mechanism can be both effective and flexible, depending on the length of the keys. The keys can be passed freely from domain to domain. In addition, access privileges can be effectively revoked by the simple technique of changing some of the locks associated with the object (Section 14.7).

8. 14.6 Access Control

   • Each file and directory is assigned an owner, a group, or possibly a list of users, and for each of those entities, access-control information is assigned.

9. 14.7 Revocation of Access Rights

   • sometimes need to revoke access rights to objects shared by different users.
   • • Immediate versus delayed. Does revocation occur immediately, or is it delayed?
   • • Selective versus general. When an access right to an object is revoked, does it affect all the users who have an access right to that object, or can we specify a select group of users whose access rights should be revoked?
   • • Partial versus total. Can a subset of the rights associated with an object be revoked, or must we revoke all access rights for this object?
   • • Temporary versus permanent. Can access be revoked permanently (that is, the revoked access right will never again be available), or can access be revoked and later be obtained again?
   • With an access-list scheme, revocation is easy. The access list is searched for any access rights to be revoked, and they are deleted from the list
   • Capabilities, however, present a much more difficult revocation problem, since the capabilities are distributed throughout the system, we must find them before we can revoke them
     • Schemes that implement revocation for capabilities include the following
       • • Reacquisition. Periodically, capabilities are deleted from each domain. If a process wants to use a capability, it may find that that capability has been deleted. The process may then try to reacquire the capability.
       • • Back-pointers. A list of pointers is maintained with each object, pointing to all capabilities associated with that object. When revocation is required, we can follow these pointers, changing the capabilities as necessary.
       • • Indirection. The capabilities point indirectly, not directly, to the objects. Each capability points to a unique entry in a global table, which in turn points to the object.
       • • Keys. A key is a unique bit pattern that can be associated with a capability. This key is defined when the capability is created, and it can be neither modified nor inspected by the process that owns the capability
         • A master key is associated with each object;
         • When the capability is exercised, its key is compared with the master key. If the keys match, the operation is allowed to continue; otherwise, an exception condition is raised
         • Revocation replaces the master key with a new value via the set-key operation, invalidating all previous capabilities for this object.
         • This scheme does not allow selective revocation, since only one master key is associated with each object.

10. 14.8 Capability-Based Systems

    • Neither system is widely used, but both provide interesting proving grounds for protection theories.
      • 14.8.1 An Example: Hydra
      • 14.8.2 An Example: Cambridge CAP System

11. 14.9 Language-Based Protection

    • it is usually achieved through an operating-system kernel, which acts as a security agent to inspect and validate each attempt to access a protected resource
    • comprehensive access validation may be a source of considerable overhead, either we must give it hardware support to reduce the cost of each validation, or we must allow the system designer to compromise the goals of protection
    • 14.9.1 Compiler-Based Enforcement
      • Kernel protection vs Compiler
        • • Security. Enforcement by a kernel provides a greater degree of security of the protection system itself than does the generation of protectionchecking code by a compiler
        • • Flexibility. There are limits to the flexibility of a protection kernel in implementing a user-defined policy, although it may supply adequate facilities for the system to provide enforcement of its own policies.
        • • Efficiency. The greatest efficiency is obtained when enforcement of protection is supported directly by hardware (or microcode)
    • 14.9.2 Protection in Java
      • Java was designed to run in a distributed environment, the Java virtual machine—or JVM—has many built-in protection mechanisms.
      • The JVM loads a class in response to a request to create instances (or objects) of that class
      • One of the most novel and useful features of Java is its support for dynamically loading untrusted classes over a network and for executing mutually distrusting classes within the same JVM.
        • Because of these capabilities, protection is a paramount concern. Classes running in the same JVM may be from different sources and may not be equally trusted.
      • When the JVM loads a class, it assigns the class to a protection domain that gives the permissions of that class
        • depends on the URL from which the class was loaded and any digital signatures on the class file.
      • It can be complicated for the JVM to determine what class is responsible for a request to access a protected resource. Accesses are often performed indirectly, through system libraries or other classes.
        • For example, consider a class that is not allowed to open network connections. It could call a system library to request the load of the contents of a URL. The JVM must decide whether or not to open a network connection for this request. But which class should be used to determine if the connection should be allowed, the application or the system library?
        • This implementation approach is called stack inspection. Every thread in the JVM has an associated stack of its ongoing method invocations. When a caller may not be trusted, a method executes an access request within a doPrivileged block to perform the access to a protected resource directly or indirectly.

Images and files in the map