SELinux-related errors when updating packages or using certain tools, after upgrade to Fedora 36

Problem

In Fedora 36, on certain systems you can see SELinux-related errors when updating packages or when using certain tools.

The errors during updating packages with dnf update can look like this:

error: lsetfilecon: (/usr/libexec/flatpak-system-helper;6232783d, system_u:object_r:flatpak_helper_exec_t:s0) Invalid argument
error: Plugin selinux: hook fsm_file_prepare failed

or like this:

Failed to resolve typeattributeset statement at /var/lib/selinux/targeted/tmp/modules/400/pcpupstream/cil:5
Failed to resolve AST
semodule:  Failed!

When running flatpak update:

Warning: Failed to get revokefs-fuse socket from system-helper: User flatpak does not exist in password file entry
Warning: Can't open system repo default: While opening repository /var/lib/flatpak/repo: opening repo: opendir(/var/lib/flatpak/repo): Permission denied

When using SELinux-related tools like setsebool:

Failed to resolve allow statement at /var/lib/selinux/targeted/tmp/modules/200/flatpak/cil:122
Failed to resolve AST

These errors make dnf package update transaction fail, and prevent you from using certain tools.

Note: Clean installs of Fedora 36 are not affected by this bug. It can only happen to Fedora 34/35 systems upgraded to Fedora 36.

Cause

SELinux in Fedora 36 removed some class definitions. In order for system upgrade to Fedora 36 to proceed smoothly, SELinux updates need to be installed also in Fedora 34/35. That includes the following updates:

Fedora 34

Fedora 35

If you upgraded to Fedora 36, but didn’t have these updates installed (see the Builds section in those updates to see individual package versions), your system might be affected by this bug.

Related Issues

Bugzilla report: https://bugzilla.redhat.com/show_bug.cgi?id=2056303

Workarounds

If you haven’t upgraded to Fedora 36 yet, make sure to fully update your system (and reboot, of course) before you start the upgrade to F36. At minimum, you need to have those updates listed in the Cause section, but it’s very recommended to update everything possible.

If you already upgraded to Fedora 36 and you’re affected by this bug, you should be able to resolve it by reinstalling SELinux packages:

sudo dnf reinstall selinux-policy-targeted swtpm snapd-selinux flatpak-selinux container-selinux osbuild-selinux

If the reinstall still complains with SELinux-related errors and fails to complete, you can try to forcefully remove affected SELinux modules before reinstalling them:

sudo semodule -X 200 -r snappy -r container -r flatpak -r osbuild -r swtpm -r swtpm_svirt
sudo dnf reinstall selinux-policy-targeted swtpm snapd-selinux flatpak-selinux container-selinux osbuild-selinux
sudo fixfiles -F onboot

Reboot afterwards and have patience, SELinux will relabel your whole filesystem during the next boot.

If you were affected by this bug, it is possible, that some of the packages, which failed to update in the past, might be incorrectly installed. After you’ve reinstalled the SELinux package as noted above, run sudo dnf check and see if it reports any issues, like duplicate packages. Ideally, its output should be empty. If it reports issues, try to solve them, e.g. by using sudo dnf remove --duplicates.

If you’re in a situation where you can’t follow this workaround guide, because you can’t even boot and log in due to SELinux errors, you can display the GRUB boot menu by hitting F8 during early boot, then edit the current kernel command line by pressing e, add enforcing=0 keyword at the very end of the linux line and hit Ctrl+x to boot. That will switch SELinux to permissive mode and should allow you to boot, log in, and follow the workaround guide.

FAQ

How can I check if my system is affected?

There are a few things you can do if you want to determine if your system is affected:

  1. Are you seeing the errors as listed above? If yes, you’re affected.
  2. Is your Fedora 36 a clean install? If yes, you’re not affected.
  3. If you have some packages installed with custom selinux-policy modules and they use socket_class_set in raw rules which expands to all currently defined classes, then you might be affected. The well-known official packages are already covered in this post, so likely these could be some low-profile/third-party packages or a local policy created by the administrator.
  4. Run sudo dnf history and find the transaction in which you performed the system upgrade to F36. Then display the transaction with sudo dnf history info ID (replace ID with the transaction number), and compare the package versions of your F34/F35 packages with the necessary package versions listed in the Cause section. If your packages were the same or newer, you shouldn’t be affected.
  5. You can run these simple heuristic commands:
$ matchpathcon /var/lib/containers
/var/lib/containers     system_u:object_r:container_var_lib_t:s0 
# good outcome

$ matchpathcon /var/lib/containers
/var/lib/containers     system_u:object_r:unlabeled_t:s0
# bad outcome

and

$ seinfo -xt container_file_t
Types: 1
   type container_file_t alias { svirt_sandbox_file_t svirt_lxc_file_t }, device_node, file_type, filesystem_type, mountpoint, non_auth_file_type, non_security_file_type, noxattrfs, ptynode, svirt_file_type;
# good outcome

$ seinfo -xt container_file_t
Types: 0
# bad outcome

If your output is bad outcome, you’re affected. If it is good outcome, you might not be.

2 Likes

An update has been released to fix this issue.

After you update your system in your usual way (and possibly reboot), you should no longer be affected by this problem. If the problem persists, please start a new discussion topic and we’ll help figure out what’s still wrong.

2 Likes

Ignore the bot, it has a tiny bug brain. Everything important is documented in the first post.

3 Likes