Hi Laurent & Sam,
On Thu, May 13, 2021 at 10:14:38AM +0200, Laurent Bigonville wrote:
> I see that you reassigned this bug to the refpolicy package and FTR I don't
> completely agree with that.
>
> Most of the other applications that manipulates SELinux objects are behaving
> nicely when they are running in permissive and the policy is not including
> the type they needed.
>
> So having the policy implement the needed types is good for a security
> perspective, but podman shouldn't fail hard (and without a clear message).
>
> This was partially addressed upstream in
> https://github.com/containers/storage/pull/879 (still need to test it)
(I'm going through older bugs in the BTS that affect podman, and trying
to verify if they're still present.)
I read through this bug, plus the associated upstream ones. I know very
little about SELinux, and the upstream bugs themselves do not provide a
ton of extra clarity.
It would help to list all steps needed to reproduce this bug.
Guessing what the problem may be, I tried the following:
1. Use the Debian sid daily cloud image and boot with QEMU, fully
up-to-date as of 2024-01-01 (happy new year ;)
2. adduser user
3. apt install --no-install-recommends podman slirp4netns uidmap
dbus-user-session
4. Verify that "podman run --rm -it debian:sid" runs:
a. as user "root"
b. as user "user" (note: do not use sudo, login in another tty instead)
5. apt install --no-install-recommends selinux-basics selinux-policy-default
auditd
6. selinux-activate
7. Reboot
8. Run "sestatus" and verify that SELinux status is "enabled" and in
permissive mode.
9. "podman run ..." as users "root" & "user" again (cf. step 3).
10. setenforce 1; sestatus | grep mode
11. "podman run ..." as users "root" & "user" again (cf. step 3).
In both steps (8) and (10), i.e. even with SELinux in enforcing mode,
both rootful and rootless podman seemed to work for me.
Note that if I install SELinux before podman (so steps 5-8 before 3-4),
then a:
restorecon -R /var/lib/containers # for rootful
or
restorecon -R $HOME/.local/share/containers # for rootless
are required, but only *after* podman initializes its directory, i.e.
after the first "podman run" invocation. I'm not sure what the SELinux
best practice is for dealing with this, but I assume nothing
podman-specific.
So, should we consider this bug as fixed? Perhaps due to
containers/storage#879 or some other fix?
Regards,
Faidon
