Create official container images and document rust-keylime agent usage on Fedora CoreOS

[travier]

This is a tracking issue for the discussion and work needed to create a container image and documentation for the rust-keylime agent to work on systems such as Fedora CoreOS.

See previous discussion in https://github.com/coreos/fedora-coreos-tracker/issues/982.

[travier]

Concerns were raised about the case where a containerized version of the agent could lock out other users of the TPM.

As far as I understand and according to https://github.com/tpm2-software/tpm2-abrmd#tpm2-abrmd-vs-in-kernel-rm, I see two use cases:

• If we are using the kernel resource manager then we need to bind mount /dev or a specific TPM device /dev/tpm* directly into the container. The kernel would then ensure no single process locks the TPM entirely. If this not doable in practice then this might not be an option.
• If we are using the tpm2-abrmd daemon which provides a DBus API then the container should be granted access to be able to connect to the host's DBus socket or a small proxy can be created to enable only selected DBus accesses (similar to how Flatpak portals works). The daemon would then manage concurrent access.

[puiterwijk]

I think just using /dev/tpmrm* is probably the easiest, it'll make sure the kernel performs the Resource Manager role. It also saves us from extra permissions (dbus) or more code (proxy).

[travier]

Note that if we go the "bind mount devices for the container" route, we can either bind mount an exhaustive list of devices at container startup time or we need to bind mount the entire /dev directory if the devices names are unknown or not present at startup time.

[kkaarreell]

Could you please elaborate on the intended container use case? Without namespaced IMA the agent cannot distinguish whether a file comes from the host, agent container or a different container. Doing attestation in such a situation would be difficult, it basically mean you are doing attestation of everything running on the host (including all containers) and the allowlist would have to reflect that. Also, what would be the impact when one of the containers fails attestation? If I am not mistaken, starting that moment we won't be able to say if other containers or host itself comply? Or maybe I am wrong.

[travier]

There are two different things:

1. Doing remote attestation from TPM PCR measurements with a remote server on boot. This use case does not require access to the full disk / other containers.
2. Doing on-going attestation / integrity checks and reacting to attestation failures events and that would require full access / running on the host / out-of-container.

I think it would be interesting to have 1. working on Fedora CoreOS, with a container approach.

I personally think that 2. is less valuable in general, especially for Fedora CoreOS use cases where reboots happen regularly and that's the moment that you really want to attest that your system is running the version that you want.