@@ -144,12 +144,18 @@ control security of the system, including but not limited to:
* logging of security-related events
* 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: 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>
# 1.3 Products not in scope
_Detailed list of things whose scope might be confusing, including parts of a system which are often included when the terms in the "in scope" section are used in general conversation. Reference the "Product Context" section again to remind the reader what operational environments are in scope._
@@ -384,6 +390,7 @@ High security level:
Very high security level:
1. Firewalls
1. Corporate server providing services on public internet
* Multiple accounts for isolation of services
* Automated management and monitoring by IT professionals
@@ -397,7 +404,7 @@ Very high security level:
* Often used by children
* Connects to various networks (home, public, mobile, ..)
* What user can do to it is highly limited by default
* User installs and runs applications from trusted sources only
* User installs and runs applications from pre-approved sources only by default
* Browses the web
* Used for sensitive transactions/data storage (e.g. banking, health data)
* Collects lots of user/usage data
@@ -408,22 +415,68 @@ Very high security level:
**Discussion**
MOVE TO STANDARDS ETSI 103 732 phones
The apps in the app store are NOT covered but the default source/method of installing apps informs risk and may be covered in some aspects
Carl-Daniel:
Separate question for the application delivery mechanism:
1. App is not preinstalled, but by default gets installed during initial configuration by the user if the user always picks the preselected option -> IMHO part of the device, forcing installation later should not be an allowed trick to make the scope smaller.
2. Third party app is installed through the official app store/repository, but vetted less (or not at all) by the OS vendor. Do we want to require a vetting level indicator if the same source has multiple tiers of vetting?
3. Third party app is installed through the official app store, but does not use that app store for updates, instead preferring its own update delivery mechanism. Is that something we should warn against?
4. App installation requires the user to agree to certain privileges/permissions for the app. If the app later on wants more/other permissions, are those granted implicitly (motivation: user has already installed the app, keep it working) or is explicit consent by the user necessary?
5. If the OS changes the way how app permissions are handled (bluetooth access suddenly needs location permission), should the OS guess the intent of the user or should the user be re-asked all the permission questions?
Aeva: Carl-Daniel's comment could also apply to enterprise computers (laptops, desktops, servers) -- most also contain a second OS for remote management.
industrial operations we have to include probably?
A few risk factors extracted from the use cases:
* Number of accounts
* Number of users: 0, 1, more than 1
* Whether users trust each other
* No trust
* Corporate colleagues level
* Family
* Children
* Purchaser vs. users
* Stationary vs. mobile
* Public vs. private environment
* Public vs. private physical environment
* Exposure to theft and loss
* Behind a firewall or directly connected to internet
* airgap
* system can reach the internet
* internet can reach the system
* Source of applications installed post-market (if any)
* Professional or amateur management
* Web browsing or not
* Sensitivy of data collected or transferred
* Sensitivity of functions
* End user configurability (how locked down)
* End user modifiability to hardware
* Running on bare metal vs. hypervisor
We may be able to use these risk factors to calculate a recommended
security level for special purpose operating systems not covered by
use cases.
Les: level of exposure to the internet (proxy for an attacker)
How easy is it for an attacker to get access?
Break down mobile as proxy for physical access, wifi, much network
game os for consoles
rtos for an oscilloscope
Carl-Daniel: Any smart phone has two operating systems anyway: The user-facing operating system (Android/iOS) and the modem/baseband operating system (usually some RTOS, usually 5 years behind with patching security holes). So the smart phone is also a nice model for compound devices.
Baseband OS - think about distinction with chips a la boot managers
Many devices have multiple OS's for elements
## 4.4 Security levels
_This will become a table of use cases by security level._
@@ -614,6 +667,37 @@ From BSI Operating Systems Protection Profile:
* User-initiated
* Trusted channel (secure network access)
MOVE BACK: profressional management might include is the audit info being watched?
Very specific
* Disable debugging interfaces in many many places
* TPM and TEE support
* Secure boot/ crypto authenticated boot
* Measured boot
* Remote attestion
* Don't require login to online account
* Make rules about opt-in being required
* Everything shipped/included by manufacturer is the responsibility of the manufacturer (would cut down on junkware)
What about commonly disabled features for minimization
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.
# Annex A (informative): Relationship between the present document and any related ETSI standards (if any)
_List any related ETSI standards and how they interact with the present document._
