docker: Add 'keylime' system user

[ansasaki]

This allows dropping privileges inside the container.

[sergio-correia]

LGTM

[codecov]

Codecov Report

Merging #635 (fd852c3) into master (8997333) will not change coverage.
The diff coverage is n/a.

Additional details and impacted files

Flag	Coverage Δ
e2e-testsuite	59.47% <ø> (ø)
upstream-unit-tests	59.79% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

[mheese]

@ansasaki I considered that and opted against it, as the mapping needs to happen between user/group of the TPM device files, and they differ between distributions, etc. and additional LSM restrictions. However, on plain docker you could use that together with the userns-remap flag, but then in general there is not too much benefit anymore to drop privileges within the container, that's already why you are running this inside of a container with no privileges, no shell, etc.pp.
Anyway, not a harmful change either :)

[ansasaki]

@ansasaki I considered that and opted against it, as the mapping needs to happen between user/group of the TPM device files, and they differ between distributions, etc. and additional LSM restrictions. However, on plain docker you could use that together with the userns-remap flag, but then in general there is not too much benefit anymore to drop privileges within the container, that's already why you are running this inside of a container with no privileges, no shell, etc.pp. Anyway, not a harmful change either :)

@mheese I have a question for you: how can the agent run in an unprivileged container and still have access to the measured boot event log (e.g /sys/kernel/security/tpm0/binary_bios_measurements)? I tried many approaches using podman, but could not find a way to provide access to that to the user from inside the container.

[aplanas]

Why not to use USER?

https://docs.docker.com/engine/reference/builder/#user

[ansasaki]

AFAIK, USER only sets which user will run the container process, it does not create an user.

And we need to run the container as root to access the files that need privilege, such as the /sys/kernel/security/tpm0/binary_bios_measurements or the TPM device.

If you know another way, please let me know.

P.S.: In the example in the documentation you provided you can see that the user was created by a separate command.

[ansasaki]

I see this as a harmless change. We can revert this later if needed.

[mheese]

@mheese I have a question for you: how can the agent run in an unprivileged container and still have access to the measured boot event log (e.g /sys/kernel/security/tpm0/binary_bios_measurements)? I tried many approaches using podman, but could not find a way to provide access to that to the user from inside the container.

@ansasaki hm, which approaches did you try? As I'm not working with "plain" podman or docker, I don't really know what issues you ran into. I have not seen any issues by using plain host directory mounts so far. However, I can imagine certain additional LSM checks getting in the way here, which I have not activated on the machines that I work with.

However, even to access the binary_bios_measurement file, you do not need to be root, you only need to be a member of the tss group. That has the same uid/gid mapping problems though, as the container uid/gid never maps to the same on the host (on purpose). This is why userns remapping was introduced to resolve those issues, so that you could let a specific container map this gid to the gid on a specific container. That said, I have not checked for some time what the adoption for this is within Kubernetes by now, which is why I was not very interested in solving this problem for now.

Taking a quick look at podman help pages, you should be able to solve this with the uidmap and gidmap flags:

• https://docs.podman.io/en/v4.4/markdown/options/gidmap.container.html
• https://docs.podman.io/en/v4.4/markdown/options/uidmap.container.html

Or you could change the whole userns altogether with this option: https://docs.podman.io/en/latest/markdown/options/userns.container.html

Anyway, please let me know your findings (even only slack is fine too)! 👍 I'm very interested in this problem.

[ansasaki]

hm, which approaches did you try? As I'm not working with "plain" podman or docker, I don't really know what issues you ran into.

I used those options to remap uid/gid, but the problem is that /sys/kernel/security/tpm0/binary_bios_measurements is owned by root:root in the host, not by the tss group (in some distros yes, but not in all distros). So, I was wondering if you had some other mechanism to provide access to that (as you said you were able to run the agent in an unprivileged container). I guess not.