Threat models

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

1. 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

OP-TEE

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.

TPM

Firmware TPM

OCI