--user flag not respected under (rootless) podman

[smithfred]

Regardless of the value of --user, pods started with (rootless) podman + krun have a UID/GID of 0 within the container.

krun:

> podman --runtime=krun run --user=1000:1000 --rm -it registry.fedoraproject.org/fedora sh -c 'id -u; id -g'
0
0

Another runtime (crun):

> podman --runtime=crun run --user=1000:1000 --rm -it registry.fedoraproject.org/fedora sh -c 'id -u; id -g'
1000
1000

[slp]

Yes, not all container semantics are supported in libkrun, but this one should be relatively easy to adopt. Could you please explain a bit the use case?

[smithfred]

In general terms, this article covers a lot of the reasons for container images to still use a different user account even in rootless mode.

For me specifically, I was using a 3rd-party containerised application that was configured to run as a non-root user witin the container. Edit: and more generally, 3rd-party containers that have been secured this way (with the expectation that they might be run under a rootful runtime), will break under libkrun otherwise.

[srprca]

Hello!

I have recently encountered the same issue, my use case being that I would like untrusted containerized workloads to run with the least possible privileges.

I understand that support for --user is not implemented yet, but I wonder what workarounds are available to drop privileges upon container entry?

For example, can I set the container entrypoint to be a runuser or setpriv command with an unprivileged user as a target? This seems to work, but I am not sure if this provides the same degree of security.

Thank you!

[slp]

I understand that support for --user is not implemented yet, but I wonder what workarounds are available to drop privileges upon container entry?

For example, can I set the container entrypoint to be a runuser or setpriv command with an unprivileged user as a target? This seems to work, but I am not sure if this provides the same degree of security.

Yes, that would have roughly the same effect. OTOH, implementing it "the right way" should be fairly trivial. We have access to the container definition from the VM, so it's just a matter of reading the desired uid/gid from init.c and using them.

[srprca]

Actually, I think I may be able to look into implementing this. Is there any documentation on how different parts of libkrun interact with each other that I could read to better understand the codebase before starting?

Thank you!

[mtjhrc]

The main thing that needs to be implemented is basically in init.c you need to set the uid/guid to the ones written to .krun_config.json by crun, before exec-ing the user payload. (init.c will still be ran as root in the guest).

In addition to that, the outer libkrun VMM may also run under USER. I am not sure what the semantics we want here (and how will it effect virtio-fs), but I think it could work for common use cases. What could make file permissions work weirdly would be if you decided to use something like sudo to elevate to root again inside the VM.

[srprca]

Thank you for your explanation!

I am not sure I understand the quoted part:

In addition to that, the outer libkrun VMM may also run under USER. I am not sure what the semantics we want here (and how will it effect virtio-fs), but I think it could work for common use cases. What could make file permissions work weirdly would be if you decided to use something like sudo to elevate to root again inside the VM.

As I understand, the VMM runs as the user who runs Podman, and running rootless Podman is the recommended scenario for most cases. Could you please elaborate?

[mtjhrc]

As I understand, the VMM runs as the user who runs Podman.

Depends how you mean it. Yes it runs with the privileges of user. But the VMM runs within the container (implemented using user namespaces) under a fake uid 0 (like normal container images). This is not the real uid 0 on the host system.

[srprca]

So do you suggest lowering the fake, namespaced privileges as well? I wonder if this helps improve security, because these privileges are not "real" to begin with.

In any case, I don't think I will be able to help with this part, because I don't know enough about the workings of containerization and namespace technologies.

I will probably look into the original issue of the user that the container workloads are executed as.

[slp]

We might also need to change crun to avoid switching to uid/gid before calling krun_start_enter, but let's cover the init.c implementation first.

[mtjhrc]

So do you suggest lowering the fake, namespaced privileges as well? I wonder if this helps improve security, because these privileges are not "real" to begin with.

Just tested it and this seems to already happen by coincidence/accident (I suspected it would).

We might also need to change crun to avoid switching to uid/gid before calling krun_start_enter

Yeah we should do that, if you become root in the VM (e.g. via sudo) the behavior gets confusing because in the guest we are uid 0, but libkrun is running under uid 1000 (user m I added to the image):

$ podman run -it --rm --runtime /home/mhrica/Dev/crun/crun --annotation run.oci.handler=krun --user m myfedora bash
[root@d9a55a875f30 /]# touch hi
touch: cannot touch 'hi': Permission denied
[root@d9a55a875f30 /]# cd ~
[root@d9a55a875f30 ~]# pwd
/home/m
[root@d9a55a875f30 ~]# touch hi
[root@d9a55a875f30 ~]# ls
hi
[root@d9a55a875f30 ~]# cd /root
[root@d9a55a875f30 root]# touch hi
touch: cannot touch 'hi': Permission denied
[m@d9a55a875f30 ~]$

[mtjhrc]

@srprca

I will probably look into the original issue of the user that the container workloads are executed as.

That would be appreciated ❤️

[RiverNewbury]

I have a commit for adding the uid/gid switching to init.c part of this but I don't understand your comment about not changing user @mtjhrc. I don't fully follow what is going on in the example of the negative behaviour you gave. Would you be able to give some more details?
Thanks