An operating system is a computer program; it is a collection of computer instructions that, when executed, provide the features we expect from the operating system. The system has separate parts to manage RAM, handle files on the hard drive, and operate I/O devices. The operating system’s dispatcher chooses which processes to run. As noted earlier, a computer can have several processes running at once even if it only has a single CPU. Different processes take turns using the available CPUs. The dispatcher switches between processes when one must wait while another gets to run.

We now look at the dispatcher program as another example of a security plan. First, we develop security requirements for process protection; then we describe the basic design of the dispatcher. We also make a list of security controls provided by the dispatcher. We use the design and the list of controls to show that the dispatcher fulfills the requirements.

To develop the requirements, we naturally start by identifying assets. In this case, the assets of interest are the control and data sections used by the different processes. The functional objectives are to provide the following operating features:

• ■   Multiple processes may share one or more CPUs.

• ■   Processes may share control sections.

• ■   Processes do not share data sections by default, but may do so on request.

The general security objective is to prevent processes from interfering with one another. Here is the list of risks:

1. One process may accidentally or intentionally monopolize the CPU.

2. One process may write data into the RAM belonging to another process.

3. One process may read data belonging exclusively to another process.

In order to identify our security requirements, we examine the risks one by one. For each risk, we identify protections that we need to ensure. In the following discussion, requirements appear in italics.

1. One process may accidentally or intentionally monopolize the CPU.

   When a process is running, the CPU is executing its instructions, one after another. The CPU will focus exclusively on that process’s instructions unless the operating system interferes. Typically, the operating system has two opportunities to interfere: first, when the process asks the operating system to perform an I/O operation, and second, when the process has been running “too long” without encountering an I/O operation.

   Our first requirement addresses the first case: (1) When the running process requests an I/O operation, the operating system shall suspend that process from execution and give the CPU to another waiting process.

   Our second requirement addresses the second case: (2) When a process has been using the CPU too long without interruption, the operating system shall interrupt that process, suspend it, and give the CPU to another waiting process.

   We should also include another requirement to restrict these controls to the operating system: (3) When the operating system starts a process running, the process shall run in user mode, not in kernel mode.

2. One process may write data into the RAM belonging to another process.

   Before we start providing access to RAM, we need to know that we are starting with a clean slate with respect to RAM access. The process can’t touch RAM, except using the access rights we specifically provide. We address this with the following requirement: (4) The operating system shall ensure that a process has no access to RAM, except those it specifically enables to implement security requirements. This is one of those tricky “global” requirements, but it is essential in this situation.

   There are two possibilities when addressing this risk. First, a process may write into a control section being used by another process. We address this with the following statement: (5) Before starting a process, the operating system shall establish read-only access to the control sections assigned to the process.

   The second possibility is that a process may write into a data section that belongs exclusively to another process. We address this first through requirement 4. Then we establish access to the process’s assigned data sections: (6) Before starting a process, the operating system shall establish read/write access to the data sections assigned to the process.

3. One process may read data belonging exclusively to another process. This is a case where one process “eavesdrops” on another. This is not always a risk—it depends on the environment—but we have listed it as a risk in this case. However, we have already addressed it in the previous risk with requirements 4 and 6.

Security Requirements for Process Protection

TABLE 2.4 lists the dispatcher’s security requirements. A good set of requirements will cover all of the significant risks. In the last section we created the requirements directly from the list of risks. We should therefore be confident that all risks are covered.

TABLE 2.4 Security Requirements for Process Protection
#	Requirement	Risks
1	When the running process requests an I/O operation, the operating system shall suspend that process from execution and give the CPU to another waiting process.	1
2	When a process has been using the CPU too long without interruption, the operating system shall interrupt that process, suspend it, and give the CPU to another waiting process.	1
3	When the operating system starts a process running, the process shall run in user mode, not in kernel mode.	1
4	The operating system shall ensure that a process has no access to RAM except those it specifically enables within the requirements.	2, 3
5	Before starting a process, the operating system shall establish read-only access to the control sections assigned to the process.	2
6	Before starting a process, the operating system shall establish read/write access to the data sections assigned to the process.	2, 3

If we receive a list of risks and associated requirements from someone else, we need to verify that the requirements cover the risks. To do this, we take the list of risks and compare them against the requirements. The first risk, of a process monopolizing the CPU, is addressed by the first three requirements. The second risk, of processes writing to the wrong RAM, is addressed by the fourth, fifth, and sixth statements. The final risk, of one process reading data belonging exclusively to another process, is addressed by the fourth and sixth statements. For the coverage to apply correctly, we must be confident that each risk is fully addressed by its corresponding requirements. This requires a clear understanding of what the risk entails and what the requirements accomplish.

Functional Security Controls

It is fairly easy to construct our list of security controls, as long as we can provide each control with a brief and clear description. This is true for many physical, mechanical, and procedural controls. The security controls for Alice’s Arts (Table 2.4) are simple to describe, so the list of controls is sufficient to address the security implementation.

The Dispatcher’s Design Description

This software design description contains two parts: the design features and the procedure. The design features identify properties of software that are outside of its own control. In other words, this is a list of properties applied to the software externally. In this case, the operating system establishes the dispatcher’s environment and enforces the design features. The software’s procedure describes the steps it performs.

The Design Features

We are looking at the operating system’s dispatcher because it carries the primary responsibility for restricting access by processes. The dispatcher creates, starts, and resumes processes, so it is responsible for granting access to sections of RAM. This description focuses on the task of switching the CPU from running one process to running a different one. Here are the design features of the dispatcher:

1. The dispatcher runs in kernel mode. This in turn requires that the CPU provide kernel and user modes.

2. The operating system calls the dispatcher after a process requests an I/O operation.

3. The operating system calls the dispatcher after a process gets interrupted for running too long.

4. A running process receives no access to RAM, except for those access permissions established by the dispatcher. This in turn requires that the CPU be able to restrict access by user mode programs.

The Dispatching Procedure

Now, we describe the steps the dispatcher takes when switching between processes.

1. The dispatcher saves the state of the previously running process.

2. The dispatcher looks for the next process to run. If another process is waiting to run, the dispatcher runs that one. If not, it may restart the previously running process.

3. The dispatcher looks at the process state for the next process to run.

4. The dispatcher establishes read-only access to RAM containing the control sections being used by the next process.

5. The dispatcher establishes read/write access to RAM containing the data sections being used by the next process.

6. The dispatcher switches from kernel mode to user mode.

7. The dispatcher runs the next process, giving it the program counter value saved in its process state.

Security Controls for Process Protection

TABLE 2.5 lists the security controls required to protect processes. The security controls used to protect processes rely on CPU features, but they are all implemented by the dispatcher software. These controls are, therefore, functional controls.

TABLE 2.5 Security Controls for Process Protection

We develop the list of controls by examining the statements made in the design description. There are four design features and seven steps listed in the description. We examine each one individually to see if it implements a requirement.

Now we review the list of security controls to see that they implement the requirements. There is at least one control to implement each requirement. If we compare the requirement against the controls that implement it, we see that the controls, in general, implement the requirements. However, it may be possible that the CPU doesn’t provide exactly the controls we want. For example, the CPU might not be able to restrict RAM access to sufficiently small pieces, and a process might be granted unintentional access to information from other processes. Gaps between the requirements’ intentions and the implementation details demand attention, because they may lead to security vulnerabilities.