Updates/cleanups of title and scope

<br />

<br />

Title;<br />

Part #: Part element of title;<br />

Sub-part #: Sub-part element of title<br />

CRA; Essential cybersecurity requirements for operating systems<br />

Release #<br />

# 1.2 Products in scope

Operating systems include software products with digital elements that provide an abstract interface of the underlying hardware and control the execution of software. They 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.

<mark>  FIXME: Link to technical definitions doc </mark>

Operating systems include software products with digital elements that 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.

This category includes but is not limited to:

* general purpose operating systems

* embedded operating systems

* special purpose operating systems

The scope is limited to the security-relevant parts of the operating

system. This includes any element capable of modifying elements that

control security of the system, including but not limited to:

The scope is limited to the security-relevant parts of the operating system. This includes any element capable of modifying elements that control the security of the system, as well as elements that provide security functionality. Security-relevant parts of the operating system include but are not limited to:

* the kernel

* device drivers supplied with the operating system

* device drivers if supplied with the operating system

* libraries used to provide security-relevant services

* authentication services

* processes running with elevated privileges

* processes capable of granting elevated privileges

* file systems allowing setuid

* package management

* update mechanism

* logging of security-related events

* software installation and update system

* logging and monitoring

* configuration of security-relevant items

proposed aeva including but not limited to ... device drivers that ship with the operating system, but not including device drivers that ship with and are loaded from hardware devices including but not limited to mainboards, storage devices, peripherals

<mark> FIXME: Anything can run with elevated privileges if root runs it... is there a mitigation here? </mark>

<mark> FIXME: not all processes with elevated privileges? </mark>

<mark> FIXME: device drivers supplied by external vendors, require certification, secure default, complex opt-in </mark>

<mark> FIXME: UEFI offers tables containing windows drivers and windows fetches and runs them. who is responsible? the manufacturer who supplied the driver with their hardware, the integrator made the decision to include. </mark>

<mark> Linux auto selection of security configuration depending on security setting of firmware "landlock?" </mark>

* security-relevant system default configuration

# 1.3 Products not in scope

* boot managers or boot loaders

* hardware, microcode, or device firmware

* device drivers not shipped with the operating system

* devices drivers that ship with and are loaded from hardware devices

Boot managers have the primary purpose of initializing the hardware after power on or reset with the goal of choosing, loading, and/or transferring execution to an operating system or other program. While many boot managers provide some or all of the services of an operating system (or are literally operating systems adapted for use as a boot manager), they are designed and intended primarily to transfer control to an operating system or other program, rather than continuously operate and provide services.

Baseband OS running on the baseband processor on most smartphones is a special case: Usually it has DMA write access to the user-facing OS (Android), on the application procesor and the user-facing OS can't protect itself against that.

Anything can run with elevated privileges if root runs it... is there a mitigation here?

# Annex A (informative): Relationship between the present document and any related ETSI standards (if any)