[DSE-Dev] Bug#984879: podman does not work on Debian with selinux loaded

[Faidon Liambotis]

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