Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#984879: podman does not work on Debian with selinux loaded
37 views
Skip to first unread message
Laurent Bigonville
May 13, 2021, 4:20:03 AM5/13/21
to
Hello Reinhard,
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)
From a SELinux policy perspective, the main problem is that the
"container" policy is 100% Red Hat specific and has not been upstreamed
and the difficulty is that the RH SELinux policy is heavily patched
compared to the debian and upstream one.
Not exactly sure what to do though.
Kind regards,
Laurent Bigonville
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)
From a SELinux policy perspective, the main problem is that the
"container" policy is 100% Red Hat specific and has not been upstreamed
and the difficulty is that the RH SELinux policy is heavily patched
compared to the debian and upstream one.
Not exactly sure what to do though.
Kind regards,
Laurent Bigonville
Sam Morris
Jun 21, 2023, 12:40:05 PM6/21/23
to
On Thu, May 13, 2021 at 10:14:38AM +0200, Laurent Bigonville wrote:
> From a SELinux policy perspective, the main problem is that the "container"
> policy is 100% Red Hat specific and has not been upstreamed and the
> difficulty is that the RH SELinux policy is heavily patched compared to the
> debian and upstream one.
Hi folks,
> From a SELinux policy perspective, the main problem is that the "container"
> policy is 100% Red Hat specific and has not been upstreamed and the
> difficulty is that the RH SELinux policy is heavily patched compared to the
> debian and upstream one.
refpolicy has a 'container' module that appears to work, it's just not
built by default.
Steps taken to test it:
1. Edit debian/modules.conf.default, adding 'container = module'
2. Run 'debian/rules build-default-policy'
3. Run 'semodule -i debian/build-default/container.pp'
4. Start a container with 'podman run --rm -it docker.io/library/debian:11 sleep inf'
5. Check the context of the sleep process with 'ps -Z <pid>'
Any chance that module could be built by default?
--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
Sam Morris
Jun 21, 2023, 1:10:03 PM6/21/23
to
On Wed, Jun 21, 2023 at 05:28:48PM +0100, Sam Morris wrote:
> refpolicy has a 'container' module that appears to work, it's just not
> built by default.
BTW, the existance of /etc/selinux/default/contexts/lxc_contexts is what
> refpolicy has a 'container' module that appears to work, it's just not
> built by default.
causes Podman to try to label containers. Which prevents it from being
able to start any container, since the container module is not
included in selinux-policy-default.
https://sources.debian.org/src/golang-github-opencontainers-selinux/1.10.0+ds1-1/go-selinux/selinux_linux.go/?hl=943#L943
> Any chance that module could be built by default?
the `lxc_contexts` file; I have the feeling it might also cause problems
with libvirt and k8s...
https://sources.debian.org/src/libvirt/9.0.0-4/src/security/security_selinux.c/?hl=650#L650
https://sources.debian.org/src/kubernetes/1.20.5+really1.20.2-1.1/vendor/github.com/opencontainers/selinux/go-selinux/selinux_linux.go/?hl=887#L887
Sam Morris
Jul 3, 2023, 5:00:05 AM7/3/23
to
On Wed, Jun 21, 2023 at 06:04:14PM +0100, Sam Morris wrote:
> On Wed, Jun 21, 2023 at 05:28:48PM +0100, Sam Morris wrote:
> > refpolicy has a 'container' module that appears to work, it's just not
> > built by default.
>
> BTW, the existance of /etc/selinux/default/contexts/lxc_contexts is what
> causes Podman to try to label containers. Which prevents it from being
> able to start any container, since the container module is not
> included in selinux-policy-default.
>
> https://sources.debian.org/src/golang-github-opencontainers-selinux/1.10.0+ds1-1/go-selinux/selinux_linux.go/?hl=943#L943
>
> > Any chance that module could be built by default?
>
> So if the module is not suitable to be built by default, please remove
> the `lxc_contexts` file; I have the feeling it might also cause problems
> with libvirt and k8s...
Actually this file should remain until Debian packages container-selinux
> On Wed, Jun 21, 2023 at 05:28:48PM +0100, Sam Morris wrote:
> > refpolicy has a 'container' module that appears to work, it's just not
> > built by default.
>
> BTW, the existance of /etc/selinux/default/contexts/lxc_contexts is what
> causes Podman to try to label containers. Which prevents it from being
> able to start any container, since the container module is not
> included in selinux-policy-default.
>
> https://sources.debian.org/src/golang-github-opencontainers-selinux/1.10.0+ds1-1/go-selinux/selinux_linux.go/?hl=943#L943
>
> > Any chance that module could be built by default?
>
> So if the module is not suitable to be built by default, please remove
> the `lxc_contexts` file; I have the feeling it might also cause problems
> with libvirt and k8s...
(which ships /usr/share/containers/selinux/contexts which replaces
/etc/selinux/default/contexts/lxc_contexts; without either file, Podman
etc. won't try to label their containers).
Faidon Liambotis
Jan 1, 2024, 4:30:05 PM1/1/24
to
Hi Laurent & Sam,
On Thu, May 13, 2021 at 10:14:38AM +0200, Laurent Bigonville wrote:
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
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
> 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)
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
0 new messages