Proposal: remove "testing only" limitation from agent: allow configurable locations for boot and IMA logs.

[galmasi]

Description of problem

The ongoing effort in attestation operator is to make the keylime agent deploy on kubernetes clusters in unprivileged pods. This requires two problems to be solved; (a) mapping the TPM device and (b) mapping the measured boot and IMA logs into said unprivileged containers.

We propose to use @mheese 's TPM device plugin container for both these roles. With minor changes, it can be expanded to map the logs in addition to the TPM device.

However, at this moment we cannot find any way to map the boot/IMA logs into their respective places in the security FS (e.g. /sys/kernel/security/tpm0/binary_boot_measurements). We can map them to other arbitrary places in the keylime agent container, however -- even in / -- and have them be accessible (readonly) to the target pod.

The gist of the proposed solution

I would like to propose to add the following functionality to the Rust Agent: let us configure the location of the boot/IMA logs in the configuration file, with the obvious reasonable defaults in place.

Security considerations

I cannot think of any serious security implications. The IMA and boot logs are never, ever trusted in any shape or fashion by the agent, by the verifier or any other component of Keylime. Substituting fakes can only lead to keylime verification failing. Therefore I do not see a viable path to subvert keylime functionality with the proposed change.

Code circumstances

The current implementation of the rust agent already has the "hidden" ability to change the location of the binary boot log, but this is a "testing only" feature. I propose to replace "testing only" with a "read configuration" option. This implies that we add at least two new configuration options. The specific naming of these options should be left to whoever proposes the PR to implement this feature.

Affected personnel

I do not have the power to make assignments in this project, but I would humbly request @aplanas @THS-on @mpeters @maugustosilva @ansasaki @ruocco to comment on the feasibility and security implications of this. I'm willing to undertake the work of the PR if the issue is deemed acceptable -- maybe with help from Angelo if he's willing -- and if no one can find an alternative to it. To be fair, I have been trying, for the last two weeks, to find an alternative involving Kubernetes magic and mounting securityfs with more privileges, and I failed miserably. I also don't think the requested change is severely disruptive to the Rust Agent.

[aplanas]

LGTM the idea of adding the parameters.

wrt to the main issue, how is the securityfs issue expressed in the container? Do you want to map the host's /sys/kernel/security/ inside the container place with different permissions? The fail is it is not visible inside the container, or that the permissions didn't change?

[galmasi]

The "normal" way is to map securityfs on top of sysfs (the mount directory is /sys/kernel/security). I have not found a way to do this correctly in an unprivileged container in such a way that the IMA/Boot logs are readable.

But the device plugin API allows mounting parts of securityfs directly in to the root FS of the container, e.g. /sys/kernel/security/tpm0/binary_bios_measurements mounts as /binary_bios_measurements and is readable inside the container. I have tested this function with a private fork of the plugin.

[ansasaki]

I couldn't find any security risk that this change could cause. I think we can go on and implement this change.

[mpeters]

My only concern is that because configuration can be overridden by env variables, it's possible that these log locations can be changed without the owner of the agent knowing. Sure it would lead to attestation failures, but it would be really hard to track down if someone has tampered with the env. So, I think this is fine as long as log messages (not debug, probably info, but maybe warn) clearly show that the paths are not the defaults. Otherwise it could be very hard to track down why it's failing and may lead people to just ignore the failures.

[mheese]

@mpeters raises a good concern IMHO. Additionally to just logging the locations, the agent should check with a stat() on the file the underlying filesystem of binary_bios_measurements and definitely warn and/or even fail if the file is not located on securityfs.

[galmasi]

@aplanas you were asking exactly what the fail is. There might still be a clever way to do this, but --

• securityfs is mounted on top of sysfs in a normal environment.
• In an [unprivileged] kube pod securityfs is basically not readable (I cannot read the relevant logs).
• However, if parts of securityfs (like the log itself) are mounted on top of / then they are readable.

I have not figured out why this is so, nor have I been able to change it. All I know is that when securityfs is mounted "the usual way" in an unprivileged pod running the keylime agent, I cannot access the logs themselves.

If you find a way to alter something in the way kube sets up mounts to allow the securityfs files to become readable in an unprivileged container, you'd solve the problem in a much more elegant way and this Issue would become irrelevant. I'd be the happiest person if that happened.

The current setup is available for inspection in the Attestation Operator -- I opened thisPR to demonstrate running keylime agents in unprivileged pods. Documentation on how to use it is forthcoming in a subsequent PR.

[ansasaki]

Closed via #665