user_namespace { create } rule not working

[penn5]

I'm using a default clean Fedora 38 install, running as a normal user.

$ podman run -it buildah
[root@fb5201be973d /]# echo -e 'FROM fedora\nRUN echo hi' > Dockerfile && buildah --isolation=chroot --storage-driver vfs bud .
Error during unshare(CLONE_NEWUSER): Permission denied
ERRO[0000] parsing PID "": strconv.Atoi: parsing "": invalid syntax 
ERRO[0000] (Unable to determine exit status)            
[root@fb5201be973d /]# exit
$ sudo tail /var/log/audit/audit.log
...
type=AVC msg=audit(1687430789.136:1239): avc:  denied  { create } for  pid=19907 comm="exe" scontext=system_u:system_r:container_t:s0:c570,c767 tcontext=system_u:system_r:container_t:s0:c570,c767 tclass=user_namespace permissive=0
...
$ dnf info container-selinux
Fedora 38 openh264 (From Cisco) - x86_64                                                                                                                      5.1 kB/s | 989  B     00:00    
Paquets installés
Nom          : container-selinux
Époque       : 2
Version      : 2.218.0
Publication  : 1.fc38
Architecture : noarch
Taille       : 67 k
Source       : container-selinux-2.218.0-1.fc38.src.rpm
Dépôt        : @System
Depuis le dé : updates
Résumé       : SELinux policies for container runtimes
URL          : https://github.com/containers/container-selinux
Licence      : GPL-2.0-only
Description  : SELinux policy modules for use with container runtimes.
$ dnf info podman
Paquets installés
Nom          : podman
Époque       : 5
Version      : 4.5.1
Publication  : 1.fc38
Architecture : x86_64
Taille       : 50 M
Source       : podman-4.5.1-1.fc38.src.rpm
Dépôt        : @System
Depuis le dé : updates
Résumé       : Manage Pods, Containers and Container Images
URL          : https://podman.io/
Licence      : Apache-2.0 and BSD-2-Clause and BSD-3-Clause and ISC and MIT and MPL-2.0
Description  : podman (Pod Manager) is a fully featured container engine that is a simple
             : daemonless tool.  podman provides a Docker-CLI comparable command line that
             : eases the transition from other container engines and allows the management of
             : pods, containers and images.  Simply put: alias docker=podman.
             : Most podman commands can be run as a regular user, without requiring
             : additional privileges.
             : 
             : podman uses Buildah(1) internally to create container images.
             : Both tools share image (not container) storage, hence each can use or
             : manipulate images (but not containers) created by the other.
             : 
             : Manage Pods, Containers and Container Images
             : podman Simple management tool for pods, containers and images

$ sudo semodule -l | grep container
container
$ id
[...] context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
$

I've tried running sudo semodule --refresh, this made no difference. I also ran sudo semodule -e container to make sure the module was enabled, but this didn't produce any output and made no difference.

However, when I manually added the policy corresponding to https://github.com/containers/container-selinux/blob/main/container.te#L891 to my system, it worked:

$ cat user_namespaces.cil 
(allow container_domain self (user_namespace (create)))
$ sudo semodule -i user_namespaces.cil
$ podman run -it buildah
[root@fb5201be973d /]# echo -e 'FROM fedora\nRUN echo hi' > Dockerfile && buildah --isolation=chroot --storage-driver vfs bud .
STEP 1/2: FROM fedora
STEP 2/2: RUN echo hi
hi
COMMIT
Getting image source signatures
Copying blob 3e6c72780d11 skipped: already exists  
Copying blob 5f70bf18a086 done  
Copying config ea84d4dc7f done  
Writing manifest to image destination
Storing signatures
--> ea84d4dc7f69
ea84d4dc7f690d846576d15b0bf5c27b6b605934cf8b49c182487d74677d1f83
[root@fb5201be973d /]# exit
$ id
[...] context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
$

I don't really understand why the rule specified in container-selinux policies isn't applying. Perhaps I'm missing some required user role or something? I don't know much about selinux so I can't hypothesize much, but it probably ought to work under the default setup.

[rhatdan]

Could you try to reinstall container-selinux, I think something blew up during the installation.

sudo dnf reinstall container-selinux -y

[penn5]

Could you try to reinstall container-selinux, I think something blew up during the installation.

sudo dnf reinstall container-selinux -y

Forgot to mention that I already did 😅

If you give me a few minutes I'll verify the issue is also present on another machine that was clean installed two days ago.

[penn5]

I'm encountering the same issue on another machine. Both are Fedora 38 Workstation, this time it was a clean install two days ago. Both of them have got a GitLab Runner on them, but it's running in its own user account and has no sepolicy (I installed it myself, the only things I added are user accounts and systemd units running podman under those users, so it shouldn't be interfering). The issue still occurs after reinstalling container-selinux on the other machine, too.

[penn5]

Right, so it works fine in a Fedora 38 live ISO in a VM (using container-selinux 2.209.0), with the exception that CAP_SYS_CHROOT is disabled by default, so I had to pass --cap-add=CAP_SYS_CHROOT to podman. I'm now going to add some storage to the VM and try installing to see if it works in an installed environment. Update: It also works in the installed environment, with container-selinux 2.209.0. I'll try installing updates, maybe this is a regression (more likely a configuration issue on my machine, though idk how it arose).

[rhatdan]

Yes CAP_SYS_CHROOT should come back on updates, make sure you fully update the system.

[penn5]

Like you said, updating brought back CAP_SYS_CHROOT. However, it also brought back the issue I was encountering initially, so it's either a regression or a bug in the update process. I'll try downgrading to 2.209.0.

[penn5]

Downgrading to 2.209.0 has fixed the issue, so this is a regression. Time for a binary search.

[penn5]

Using packages from https://koji.fedoraproject.org/koji/packageinfo?packageID=23542, build 2.213.0-1 works fine while 2.215.0-1 and 2.215.0-2 do not work.

[penn5]

Installing from source with make && sudo make install-policy works on 2.218.0, so it is a packaging issue.

[penn5]

You can see the bug in detection at https://kojipkgs.fedoraproject.org//packages/container-selinux/2.218.0/1.fc38/data/logs/noarch/build.log

Basically if rhel is undefined, then 0%{?rhel} <= 9 evaluates to true because 0 <= 9 (and vice versa for fedora), so one branch of the %if was always true.

[dustymabe]

Thanks @penn5 for reporting and fixing this bug. I hit it and can confirm it's now fixed.