Security

Hardening Flags

By enabling the security features established by Project Cassini, TRS distribution images can be hardened to limit potential sources or vectors of security vulnerabilities. Currently this is achieved by enabling a couple of different DISTRO_FEATURES. to:

  • Force password update for each user account after first logging in. An empty and expired password is set for each user account by default.

  • Enhance the kernel security, kernel configuration is extended with the security.scc in KERNEL_FEATURES.

  • Enable the ‘Secure Computing Mode’ (seccomp) Linux kernel feature by appending seccomp to DISTRO_FEATURES.

  • Ensure that all available packages from meta-openembedded, meta-virtualization and poky layers are configured with: --with-libcap[-ng].

  • Remove debug-tweaks from IMAGE_FEATURES.

  • Disable all login access to the root account.

  • Sets the umask to 0027 (which translates permissions as 640 for files and 750 for directories).

Threat models

Note

This threat model section will be reworked and some of the information in here will be moved over to the firmware section.

We’re leveraging the MITRE D3FEND threat model matrix as a basis for the threat modeling work in the TRS. Although MITRE D3FEND is more aimed at regular PC use, we believe it is a good and comprehensive summary of potential attacks to a lot of use cases in TRS. MITRE D3FEND covers the generic type of threats. In addition to that we will also identify the specific threats based on the assets that we’re trying to protect. Re-use is key here, the first use-cases that we implement will cover quite a bit of mitigation techniques. For new use cases we anticipate that these should be able to leverage mitigations already implemented for other use cases.

Use cases

Attested containers

Assets
Assets in attested containers

Asset

Description

Private key(s) used to sign the container images.

Private keys will be used to sign the container images.

Public key(s) used to verify signature.

Although not secret, they must be immutable in the system.

PCR registers in the TPM

They tell the true and expected state of a system.

Audit log files

Files under /var/... tracking events in the form of audit logs.

Authentication Tokens

When leveraging backends, it’s common to get an authorization token from the backend provider.

Environment variables

Tokens and passwords sometimes needs to be stored in environment variables.

Kernel command line

Information provided via Linux kernel commandline could be vital (for the security of the system).

U-Boot commandline

Should be locked down on a production system to avoid system modification.
Hardening
Threat model attested containers

Threat

Description

Mitigation

Insecure configuration (D3-ACH)

Software sometimes comes with default configurations that aren’t secure.

  • Follow the TF-A, OP-TEE, TPM (fTPM) recommended configurations for building a secure product.

  • Follow recommendations telling how to configure OCI-based containers for security oriented end products.

Physical access to configuration

The device can be deployed in a location where people have physical access to the device, which also means that they might try to change configurations.

  • Boot time integrity checking of configurations.

  • Run-time integrity checking of configurations using for example IMA (D3-FH).

Bootloader Authentication

A legitimate user could try to replace or modify the firmware binaries.

  • Signature verification using RSA or ECDSA. (D3-BA, D3-FV)

  • Measured boot (D3-TBI)

Corrupting memory

An attacker can try to modify memory to gain control of the execution (ROP, JOP attacks etc).

  • Pointer Authentication (PAC) - requires Arm v8.3A. (D3-PAN)

  • Branch Target Identification (BTI) - requires Arm v8.5A.

  • Memory Tagging Extension (MTE) - requires Arm v8.5A.

  • Stack Frame Canary Validation (D3-SFCV) using for example GCC and -fstack-protector.

  • ASLR (D3-SAOR) to randomize base addresses.

Disk modification

An attacker physically move a disk or boot the machine in another OS and then try to alter the content on the disk.

Containers accessing host resources

Containers can run with elevated privleges, which can affect the security of the system.

  • Avoid using --privileged, but at least document when using it and state why it is needed and what potential risks are.

  • Enable Mandatory Access Control (MAC) in form of Seccomp, SELinux etc.

  • Leverage cgroups to limit the access to system resources.

Container modification

An attack can try to replace or modify the container.

  • Sign and verify containers (also see podman image trust, podman image sign).

  • Measure containers - Leverage TPM or fTPM to measure the containers (extend PCRs).

Security vulnerabilities present in the container image

The container image may contain binaries that might have known vulnerabilities and could be use as an exploit.

  • Regularly update the binaries in the container image, so the binaries in the container image always is up-to-date.

  • Run scanners in the container image to find vulnerable binaries.

PKI key replacement

An attacker could try to change the public keys used to verify signed images.

  • Make public keys immutable.

  • Leverage chain-of-trust all the way from the boot ROM.

  • Use certificates to assure the owner and origin of a public key.

Changed PCR values

An attacker could try to update PCR values at random points all the way from the boot and when the system is fully up and running. A succesful attack like this would work as a denial of service attack, since it wouldn’t be possible to make a successful remote attestation.

  • Give only administers permission to update PCRs.

  • Enable Mandatory Access Control (MAC) in form of Seccomp, SELinux etc.

  • Leverage cgroups to limit the access to system resources.

Network access

Open ports and unnecessary services may expose an attack surface.

  • Leverage firewalls.

  • Disable unused services.

Leverage debug capabilities

On a production system there is probably no need to have debugging capabilities enabled by default.

Disable ptrace (Fedora example) or use other ways to disable the possibility to attach to other processes.

Multitenancy environment

A legitimate administrator could get access to the containers and the content running inside the container.

This is the case where we need confidential computing support, something like Arm CCA. However, that technology is still under development, so until then we won’t be able to do much about. Also, running things in Realms will be different compared to running in a container, so things are not directly comparable.

Establish a reverse tunnel

An exploit giving a shell could give an attacker the opportunity to setup a reverse tunnel.

Prevent the initiation of outbound traffic.

DNS spoofing (D3-DNSTA)

When use cases consisting of devices communicating with each other there is a risk that someone spoof the DNS resolution. Argueable there are other mechnisms (signature verification on downloadables etc) that would prevent potential security implications by not protecting DNS resolution.

Introduce DNSSEC at devices exposing services to clients.

Other projects threat models

TF-A

TrustedFirmware-A (TF-A) gives its analysis for threat model (ARM-TFA-THREAT-MODEL) and provides insecure configurations to mitigate potential threat. TRS suggests to enable these insecure configurations for a production ready build, the relevant flags are listed as below.

TrustedFirmware-A (TF-A) insecure configurations

Inscure configurations

Description

ENABLE_STACK_PROTECTOR=strong

Enable the stack protection checks in GCC, the stack protection level “strong” is suggested.

BRANCH_PROTECTION=1

Enable the branch protection feature, setting to 1 means “Enables all types of branch protection features”, it requires ARMv8.3 Pointer Authentication and ARMv8.5 Branch Target Identification are supported. Otherwise, if the CPUs on your platform cannot support one or both of these two CPU features, you need to select other values or event disable branch protection with setting value to 0. The detailed information can be found in the document ARM-TFA-BUILD-OPTIONS. To be able to leverage and build this feature, two additional flags needs to be enabled: CTX_INCLUDE_PAUTH_REGS=1 and ARM_ARCH_MINOR, we must pick the value for ARM_ARCH_MINOR based on the CPU architecture version, e.g. when validate on QEMU aarch64 with support Armv8.5 architecture, we set ARM_ARCH_MINOR=5 for this case.

DECRYPTION_SUPPORT=aes_gcm

Select the authenticated decryption algorithm for firmware.

ENCRYPT_BL31=1

Enable encryption for BL31 firmware.

ENCRYPT_BL32=1

Enable encryption for BL32 firmware.

KEY_ALG=rsa / KEY_SIZE=4096

Select the RSA algorithm for the PKCS keys and signing keys and the key size is 4096. When the large key size (4096) is used instead of the default key size of 2048, the product is better protected.

MEASURED_BOOT=1 / EVENT_LOG_LEVEL=10 / TPM_HASH_ALG

Enables measured boot option MEASURED_BOOT=1 when a platform supports TPM, we can emulate TPM with the tool swtpm on QEMU platform, the details for enabling TPM on QEMU can be found in the document QEMU-TPM. Setting EVENT_LOG_LEVEL=10 for only printing out TPM error log. TPM are used not only by TF-A but also by bootloaders and operating systems, usually the TPM PCR bank algorithm is chosen by later bootloader, this is reason why TF-A needs to explicitly specify TPM hash algorithm (e.g. set TPM_HASH_ALG=sha256) which is chosed by later bootloader and avoid incompatible issue between them.

DRTM_SUPPORT=1

Enable Dynamic Root of Trust for Measurement (DRTM).

As a reference, the TF-A recipe (QEMU-AARCH64-RECIPE) will enable above insecure configurations for building booting images for QEMU aarch64.

OP-TEE threat model

TBD

Invoking the TEE from a container

Containers can access the services provided by OP-TEE as long as:

  • The OP-TEE client libraries (`optee-client` package) are installed in the container

  • The /dev/tee0 device is exposed to the container. With Docker, this is achieved via --device /dev/tee0. For example:

    $ docker run -it --device /dev/tee0 <docker-image>

With such a configuration, only the client side is deployed in the container; all the other components of the TEE are on the host. This includes:

  • The OP-TEE kernel driver

  • The MMC RPMB kernel driver (when OP-TEE’s `CFG_RPMB_FS` is enabled)

  • The tee-supplicant process

  • The files created in the host’s root filesystem by tee-supplicant to provide storage for TEE persistent objects (when OP-TEE’s CFG_REE_FS is enabled)

  • The OP-TEE OS

  • The Trusted Applications binaries (`*.ta` files)

More complex configurations are possible, for example:

  • Running tee-supplicant in a container. For this dev/teepriv0 has to be shared with the container via --device /dev/teepriv0. Only one instance of the supplicant process may be running at any given time, so the host instance has to be stopped before the container is started.

  • Loading Trusted Application from a container or moving secure storage into a container. tee-supplicant loads TAs from /lib/optee_armtz and manages data files for secure storage in /data/tee by default. Therefore, Docker bind mounts as well as host overlay mounts may be used to compose things in a creative way.

U-Boot threat model

Unlike TF-A, U-Boot doesn’t give any offical documentation for handling potential threats. Below lists insecure configurations which are suggested by TRS for a production ready build.

U-Boot insecure configurations

Insecure configurations

Description

CONFIG_TPM / CONFIG_EFI_TCG2_PROTOCOL / CONFIG_EFI_TCG2_PROTOCOL_EVENTLOG_SIZE

Support TPM device on the platform, and enabling EFI_TCG2 configurations to produce EventLog with the TPM.

CONFIG_TEE / CONFIG_RNG_OPTEE

Enable driver for OP-TEE and create connection with secure world’s OP-TEE firmware. Enable the OP-TEE based Random Number Generator.

CONFIG_EFI_RUNTIME_UPDATE_CAPSULE / CONFIG_EFI_CAPSULE_FIRMWARE / CONFIG_EFI_CAPSULE_FIRMWARE_RAW / CONFIG_EFI_CAPSULE_FIRMWARE_FIT

With these configurations, we can update the U-Boot image using the UEFI firmware management protocol (fmp). Enable CONFIG_EFI_CAPSULE_FIRMWARE_FIT to support FIP image with using the same protocol.

CONFIG_CMD_EFICONFIG / CONFIG_CMD_BOOTMENU / CONFIG_AUTOBOOT_MENU_SHOW / CONFIG_BOOTMENU_DISABLE_UBOOT_CONSOLE

Enable the first three configurations CONFIG_CMD_EFICONFIG and CONFIG_CMD_BOOTMENU, U-Boot supports UEFI menu interface. After enabled the configuration CONFIG_AUTOBOOT_MENU_SHOW, UEFI menu can be shown up automatically. To only disply UEFI menu and disable U-Boot console, we can enable the configuration CONFIG_BOOTMENU_DISABLE_UBOOT_CONSOLE, in this case, we also need to remove configuration CONFIG_PREBOOT so can avoid adding boot manager entry in UEFI menu. Please see the details in the document UBOOT-EFICONFIG.

CONFIG_SILENT_CONSOLE

With configuration CONFIG_SILENT_CONSOLE and append “silent=1” into the U-Boot environment (e.g. append it into the macro CONFIG_EXTRA_ENV_SETTINGS), we can totally mute console for U-Boot.

TPM threat model

TBD

Firmware TPM threat model

TBD

OCI

TBD