operating system -> product in requirements and risk assessment

### 5.2.X.x Requirement

The operating system shall protect security-relevant memory addresses from unauthorized access by executables under the operating system's control, including the operating system itself. This includes system memory, storage addressable via memory mapping, memory for I/O devices, and anything else accessible via the memory-related instructions in the platform.

The product shall protect security-relevant memory addresses from unauthorized access by executables under the product's control, including the product itself. This includes system memory, storage addressable via memory mapping, memory for I/O devices, and anything else accessible via the memory-related instructions in the platform.

The operating system does not need to protect against unauthorized access by elements of the platform it is running on (e.g. CPU microcode, devices on the system bus, other operating systems in the device, a hypervisor). Future iterations of the standard may add this requirement for appropriate use cases.

The product does not need to protect against unauthorized access by elements of the platform it is running on (e.g. CPU microcode, devices on the system bus, other operating systems in the device, a hypervisor). Future iterations of the standard may add this requirement for appropriate use cases.

#### 5.2.X.x **MI-SSCA**: Static source code analysis for memory errors

The manufacturer shall check all security-relevant parts of the operating system for memory errors using a source code analysis tool that detects at least the following types of memory errors, subject to whether each error is possible in the source code language:

The manufacturer shall check all security-relevant parts of the product for memory errors using a source code analysis tool that detects at least the following types of memory errors, subject to whether each error is possible in the source code language:

* buffer overflow

* use after free

All warnings, annotations, or other method of suppressing warnings from the analysis tool shall be accompanied by an explanation of why the code in question will not produce an error under reasonably foreseeable use or misuse.

* Test: run a source code analysis tool on all security-relevant parts of the operating system

* Test: run a source code analysis tool on all security-relevant parts of the product

* Result: no warnings or suppression of warnings that do not have documentation showing why they are memory safe

* Output: the output of the source code analysis checker

* False negative test: for each kind of memory error in the above list, write a test program with the error, run the analysis tool on it, and show that it produces a warning for each error

The manufacturer shall implement MI-SSCA.

The operating system shall implement mechanisms to prevent unauthorized access to the memory used by security-relevant parts of the operating system. The operating system shall use user identifiers, discretionary access control, or mandatory access control to prevent unauthorized access of memory owned by user accounts by other user accounts.

The product shall implement mechanisms to prevent unauthorized access to the memory used by security-relevant parts of the product. The product shall use user identifiers, discretionary access control, or mandatory access control to prevent unauthorized access of memory owned by user accounts by other user accounts.

* Test: from a user account, attempt to read, modify, and execute security-relevant parts of operating system memory that the user is not authorized to access in this way

* Test: from a user account, attempt to read, modify, and execute security-relevant parts of product memory that the user is not authorized to access in this way

* Result: failure to access memory

* Output: error message logged by the test

The manufacturer shall implement MI-SCCA.

The operating system shall implement mechanisms to prevent the creation of a user account if one already exists.

The product shall implement mechanisms to prevent the creation of a user account if one already exists.

* Test: create one user account, then attempt to create a second

* Result: first user account creation succeeds, second fails

The manufacturer shall implement MI-SCCA.

The operating system shall implement MI-MMAC.

The product shall implement MI-MMAC.

The operating system shall implement mechanisms to reject a user account from logging in if a different user account is already logged in.

The product shall implement mechanisms to reject a user account from logging in if a different user account is already logged in.

* Test: with one user logged in, attempt to log in as a second user

* Result: failure to log in

#### 5.2.X.x **MI-PMSC** Prevent memory leaks through microarchitectural side channels in provided executables

The operating system shall implement MI-MMAC.

The product shall implement MI-MMAC.

The operating system shall implement mechanisms to prevent the executables it provides from leaking memory data to unauthorized users through known exploitable microarchitectural side channels (MASCs), such as via the observing the time of cache access for various operations, for exapmle:

The product shall implement mechanisms to prevent the executables it provides from leaking memory data to unauthorized users through known exploitable microarchitectural side channels (MASCs), such as via the observing the time of cache access for various operations, for exapmle:

* speculative execution/loads/stores

* branch prediction

* memory access patterns

* prefetching

The manufacturer shall document on which platforms the operating system mitigates known MASC leaks.

The manufacturer shall document on which platforms the product mitigates known MASC leaks.

* Test: for each type of known MASC leak on each supported platform, run a test that detects if an unprivileged user can use the MASC leak to gain unauthorized access to data in memory from security-relevant executables

* Result: tests report that MASC leak can not be used in this way

#### 5.2.X.x **MI-ASLR** Address Space Layout Randomization

The operating system shall enable Address Space Layout Randomization (ASLR) by default for all processes to mitigate exploitation of memory corruption vulnerabilities.

The product shall enable Address Space Layout Randomization (ASLR) by default for all processes to mitigate exploitation of memory corruption vulnerabilities.

#### 5.2.X.x Mapping of mitigations to risk factors and security profiles

**[TH-USDA]:** An attacker may read or modify security-relevant data without proper authorization while stored or in transmission.

**[TH-DATA]:** An attacker may read or modify data without proper authorization while being processed, stored, or transmitted by the operating system.

**[TH-DATA]:** An attacker may read or modify data without proper authorization while being processed, stored, or transmitted by the product.

**[TH-FUNC]:** An attacker may use or modify functions of the operating system without proper authorization.

**[TH-FUNC]:** An attacker may use or modify functions of the product without proper authorization.

**[TH-TRCH]:** An attacker may access or intercept the establishment of a communication channel over a network with a trusted system without proper authorization, or masquerade as a trusted system during the establishment.

**[TH-NETA]:** An attacker may transmit or access data over the network without proper authorization.

**[TH-MASQ]:** An attacker may masquerade as the operating system itself to access data in remote systems without proper authorization.

**[TH-MASQ]:** An attacker may masquerade as the product itself to access data in remote systems without proper authorization.

**[TH-DOSE]:** An attacker may prevent the performance of the essential functions of the operating system by overloading system resources.

**[TH-DOSE]:** An attacker may prevent the performance of the essential functions of the product by overloading system resources.

**[TH-DOSA]:** An attacker may use the unauthorized access to the operating system to prevent the performance of the essential functions of other devices.

**[TH-DOSA]:** An attacker may use the unauthorized access to the product to prevent the performance of the essential functions of other devices.

**[TH-CONF]:** An attacker may read or modify configuration data of the operating system without proper authorization.

**[TH-CONF]:** An attacker may read or modify configuration data of the product without proper authorization.

**[TH-UPDA]:** An attacker may cause unauthorized software updates to be installed or prevent authorized software updates.

### C.3.1 Proper platform

**[AS-PP]:** The platform the operating system runs on is trustworthy. The OS may choose to detect and/or correct hardware errors.

**[AS-PP]:** The platform the product runs on is trustworthy. The OS may choose to detect and/or correct hardware errors.

### C.3.2 Proper administrator

**[AS-PA]:** The operating system administrator is not intentionally hostile and is engaging in good faith efforts to administer the system properly.

**[AS-PA]:** The product administrator is not intentionally hostile and is engaging in good faith efforts to administer the system properly.

### C.3.3 Attacker has limited physical access to operating system

### C.3.3 Attacker has limited physical access to product

**[AS-LP]:** An attacker will have only temporary physical access to the operating system.

**[AS-LP]:** An attacker will have only temporary physical access to the product.

### C.3.4 Attacker has limited resources