Commit 0908f7e3 authored by Aeva Black's avatar Aeva Black Committed by Aeva Black
Browse files

update Section 4 up to 4.3.3

parent 05d7d526
Loading
Loading
Loading
Loading
+24 −57
Original line number Diff line number Diff line
@@ -342,6 +342,8 @@ For the purposes of the present document's risk analysis, the following abbrevia

# 4 Product context

**_Editor's Note_: _This Section Is Stable_**

## 4.1 Intended purpose and reasonably foreseeable use

The intended purpose of this product is to provide an abstract interface of the underlying hardware and control the execution of software, and that may provide services such as computing resource management and configuration, scheduling, input-output control, managing data, and providing an interface through which applications interact with system resources and peripherals.
@@ -350,46 +352,11 @@ Its reasonably foreseeable use is to facilitate the use of computing hardware an

## 4.2 Essential functions

An operating system may provide, depending on the hardware available and its configuration:
An operating system shall provide essential functionality based on the foreseeable risks specific to the product context. The essential functions may depend on available hardware or network resources, intended and foreseeable use, user configuration, and other environmental factors. 

* Resource allocation
  * Memory management
  * Scheduling
  * Storage quotas
  * Other resource usage limits
* Isolation
  * Memory protection
  * Storage protection
  * Other permissions
* Abstract I/O
  * Network stack
  * File systems
  * Video
  * Sound
  * Input devices (mouse, keyboard)
* Hardware communication
  * Device drivers
* Power management
* Hardware management
* Configuration
  * Software to run
  * Hardware configuration
  * I/O configuration (network, etc.)
* Initialization
  * Initialize hardware
  * Start software services
* Authentication
* Authorization
* Software management
  * Software verification
  * Software installation
  * Security updates
  * Software upgrade
  * Software removal
  * Firmware upgrades
  * Load kernel modules
* Logging
* Monitoring/notifications
The essential functions may include functions such as: process isolation, memory isolation, I/O abstraction, device driver management, user authentication and access control, event logging, software management, device firmware management, secure updates, and more.

The essential functions of an operating system shall be documented.

## 4.3 Product architecture

@@ -397,33 +364,34 @@ An operating system may provide, depending on the hardware available and its con

An operating system abstracts the hardware, allocates resources, and provides services to itself and any other software on the system. It often serves as a central organizing authority that controls access to system resources by various pieces of software, dividing up available resources among the applications and its own subsystems to meet implicit or explicit goals or constraints. An operating system often uses a large part of the resources of the system it runs on, but in return it simplifies the development and deployment of the overall system.

![Figure 1: Temporary architecture diagram](media/architecture.png)
![Figure 1: architecture diagram](media/architecture.png)

> FIXME: GitLab pipeline doesn't work with mermaid

Operating system architecture is quite varied, depending on factors such as the intended use case, the underlying platform, and the design philosophy of the developers. This overview will focus on the elements of operating system architecture that have a significant impact on the security functions and risk mitigations of an operating system.
Operating system architecture varies widely and depends on many factors, including the intended use case, the underlying platform, and the design philosophy of the developers. This overview will focus on the elements of operating system architecture that have a significant impact on the security functions and risk mitigations of an operating system.

### 4.3.2 Operating system security functions

The security of an operating system relies heavily on properly controlling the instructions executed by the system processor. Instruction flow is dependent on the program instructions, any data it accesses, and any hardware that has the ability to change either data or which instructions are being executed. For example, a network interface adapter can write directly to system memory, potentially altering data values and thereby influencing the behavior of running programs or even causing unintended code execution. A USB controller can raise an interrupt which can cause the interrupt controller to force the CPU to switch to executing interrupt handling code, altering the instruction flow.
The security of an operating system relies heavily on properly controlling the instructions executed by the system processor. Instruction flow is dependent on the program instructions, any data it accesses, and any hardware that has the ability to change either data or which instructions are being executed. 

Example #1: a network interface adapter can write directly to system memory, potentially altering data values and thereby influencing the behavior of running programs or even causing unintended code execution. 

A fundamental building block of operating system is privileges. Privileges determine which system resources or functions a program is allowed to access. The operating system grants a specific set of privileges to itself, its subsystems, and user-level programs, ensuring that each component operates within defined boundaries to maintain system security and stability.
Example #2: a USB controller can raise an interrupt which can cause the interrupt controller to force the CPU to switch to executing interrupt handling code, altering the instruction flow.

Generally privileges are enforced using hardware features such as a memory management unit and processor-defined privilege levels. If the hardware does not provide these features, the operating system may use a best effort approach, such as relying on the compiler to generate code that is less likely to accidentally interfere with the functions of the operating system or other parts of the system. A best-effort approach is only acceptable in low-risk, low-impact use cases where all elements and users of the systems can be trusted to not deliberately attempt to compromise the system.
A fundamental building block of most operating systems is the principle of "privilege". Privilege determine which system resources or functions a program is allowed to access. The operating system grants a specific set of privileges to itself, its subsystems, and user-level programs, ensuring that each component operates within defined boundaries to maintain system security and stability.

Generally, privileges are enforced using hardware features such as a memory management unit and processor-defined privilege levels. If the hardware does not provide these features, the operating system may use a best effort approach, such as relying on the compiler to generate code that is less likely to accidentally interfere with the functions of the operating system or other parts of the system. A best-effort approach is only acceptable in low-risk, low-impact use cases where all elements and users of the systems can be trusted to not deliberately attempt to compromise the system.

### 4.3.3 High-level operating system architectures

Operating systems architecture varies in many ways. Some of the most security-relevant ways include:
Operating systems architecture can vary in many ways which significantly affect security outcomes for the product. For this reason, the present document does not attempt to define specifics of operating system architecture. Some exmaples of differences include:

* Proportion of operating system code running in different protection domains
* Whether applications run in a separate protection domain from the operating system
* Method of communication between protection domains
* the proportion of operating system code executed with different privileges
* whether application code is executed with the same privileges as the operating system
* the method of communication between processes with different privileges
* the degree of reliance on hardware capabilities to enforce privilege separation and process isolation

Each of these design variations makes different tradeoffs between security, performance, and ease of implementation.

Reducing the proportion of code running at the highest privilege level improves security by reducing the amount of vulnerable code, at the cost of lower performance due to the need to switch between privilege domains more often. Applications running in a separate protection domain dramatically reduces the amount of vulnerable code on most systems, again at the cost of lower performance when switching between protection domains. The method of communication between protection domains is generally a tradeoff between the speed of shared memory and the safety of checking and copying specific data (e.g., directly reading/writing a region of shared memory vs. using a system call or interprocess communication interface).

A few of the more common operating systems architectures include:
A few common operating system architectures are described below for reference, but should not be taken normatively.

**Monolithic kernel:** The operating system kernel is one executable running at the highest processor privilege level in one memory domain, providing the majority of system-wide services. Applications are in separate memory domains and have a lesser privilege level. Applications request services and resources via system calls. Often a monolithic kernel supports modules, which allows parts of the kernel of the kernel to be added or removed at run-time, but they are usually sharing the same memory domain and privilege level.

@@ -435,11 +403,10 @@ A few of the more common operating systems architectures include:

**Unikernel:** The operating system and the application are effectively a single executable. Often this is described as a library operating system: a set of library routines that an application can include and effectively become the operating system.

Note that in many cases, system libraries and applications are necessary for the function of the operating system, and are included in the security-relevant parts of an operating system. Some examples include the init process, userspace helpers to set up or access USB devices, authentication software, and libraries that wrap or simplify the process of making system calls.

### 4.3.3 Access control mechanisms
### 4.3.4 Access control mechanisms

Operating systems control access to resources in different ways, including:
Operating systems may control access to resources in different ways, including but not limited to:

**Access control lists:** Each resource has a list of users or processes that are allowed to access it.