Incompatible with container-selinux > 2.188

[ameyp]

I'm running Fedora CoreOS 37.20221211.3.0, and I've installed both container-selinux-2.193.0 as well as k3s-selinux-1.2-2.el8 (from https://github.com/k3s-io/k3s-selinux/releases/download/v1.2.stable.2/k3s-selinux-1.2-2.el8.noarch.rpm). However, the k3s module doesn't appear to be getting loaded on the system, the output of semodule -l does not contain k3s. Additionally, if I try to install the module manually with semodule -i <path>, it fails due to a conflict:

[root@localhost core]# semodule -i /usr/share/selinux/packages/k3s.pp
Conflicting name type transition rules
Binary policy creation failed at /etc/selinux/targeted/tmp/modules/400/k3s/cil:135
Failed to generate binary
semodule:  Failed!

The error leads me to believe that one of rules specified in this package is conflicting with a rule in one of the existing modules.

[ameyp]

The actual problem that I'm trying to solve, is that /var/lib/rancher/k3s/storage is being created with the label container_var_lib_t instead of container_file_t, thereby causing the local-path provisioner to fail with permission denied.

[wranders]

Having this problem as well. From the CIL, the offending statement is

(typetransition container_runtime_t container_var_lib_t dir "snapshots" container_share_t)

which comes from

k3s-selinux/policy/centos8/k3s.te

Line 36 in d97be9f

filetrans_pattern(container_runtime_t, container_var_lib_t, container_share_t, dir, "snapshots")

I tried looking through container-selinux for anything that would conflict from the previous integration of k3s rules, but didn't find anything.

This is occurring in 37.20221225.3.0 as well. Here are the package versions used:

• selinux-policy-37.16-1.fc37.noarch
• selinux-policy-targeted-37.16-1.fc37.noarch
• container-selinux-2:2.193.0-1.fc37.noarch

These were manually upgraded to the latest release version and made no difference.

[mysticaltech]

@brandond Having the exact same issue on OpenSUSE MicroOS latest!

Our project just came to an halt. See mysticaltech/terraform-hcloud-kube-hetzner#528 (comment)

When trying with semodule -vv -i /usr/share/selinux/packages/k3s.pp

It gives those issues:

Please, how do we fix this? It's kind of urgent as many daily installs are now failing.

[brandond]

The EL8 policy should work with container-selinux 2.167.0-1 and selinux-policy 3.14.3-67, which seems to work fine on both EL8 and EL9. We don't technically support CoreOS so I can't speak as to specific compatibility with any of the packages on that distro.

For MicroOS, it should work with container-selinux 2.164.2-1.1 and selinux-policy 20210716-3.1. If you're having trouble with MicroOS, please verify what version of those packages you're using. I suspect that something has been updated on the MicroOS side that is now conflicting, but I don't track that distro closely enough to know what off the top of my head.

[mysticaltech]

@brandond Yes, we suspected that too, as it was working yesterday, and since the latest release that just dropped, the problem showed up!

Will have a look at those packages' versions, and at ways to downgrade them.

[brandond]

With regards to selinux and local-path-provisioner, that is maintained by another team - the same team that owns Longhorn, to be specific. I believe they have an issue in their backlog to improve its compatibility with selinux and PSA.

[mysticaltech]

@brandond Indeed the versions on MicroOS are significantly more recent. I will investigate which of these packages were updated since yesterday.

[mysticaltech]

@brandond Thanks for your tips, as always very helpful!

After investigating the aforementioned packages here https://download.opensuse.org/tumbleweed/repo/oss/noarch/. We can see that it was container-linux that was upgraded just recently from 2.188 to 2.198.

So, downgrading with transactional-update --no-selfupdate -n pkg install --oldpackage https://download.opensuse.org/tumbleweed/repo/oss/noarch/container-selinux-2.188.0-2.1.noarch.rpm did work! 🎉

After that, applying semodule -vv -i /usr/share/selinux/packages/k3s.pp does successfully build the policy binary.

However, I blocked future automated upgrades of container-selinux with --no-selfupdate to avoid issues upon automatic upgrade back to 2.198 when the node is running.

But will that affect the security of the node and/or future versions of k3s? And is it really necessary to do so (lock the version)? Just so you understand the context, our nodes on Kube-Hetzner are meant to remain evergreen, by combining MicroOS's automatic upgrades, and the system-upgrade-controller for k3s.

Since the policy has been built successfully already, if we leave the automatic upgrade on for that package, would it fail to run under the more recent container-selinux 2.198 ?

[brandond]

The updates are listed at https://build.opensuse.org/request/show/1059620 but I don't see anything obvious that would break it, so I'll take some additional research. I believe that some of the suspicions I saw about the problem being the same as whatever's affecting Fedora CoreOS are correct.

[mysticaltech]

Ok, good to know! If you need any command outputs or logs, please don't hesitate! 🙏

[mysticaltech]

Sadly, it is confirmed; even the automatic upgrade breaks it because it tries to rebuild the policy! So locking of the version is important until the definite fix is shipped.