sec-policy/flatcar-selinux-patches: add Calico fix

[tormath1]

This fixes a denial starting from Calico 3.32.2. (See: projectcalico/calico#13685 as well)

Testing done

To be tested with: flatcar/mantle#943

• Changelog entries added in the respective changelog/ directory (user-facing change, bug fix, security fix, update)
• Inspected CI output for image differences: /boot and /usr size, packages, list files for any missing binaries, kernel modules, config files, kernel modules, etc.
• CI: https://jenkins.flatcar.org/job/container/job/packages_all_arches/628/cldsv/

I'll do best effort to backport this on other channels.

[Copilot]

Pull request overview

Updates the Flatcar downstream sec-policy patchset to address a new SELinux denial seen with Calico ≥ 3.32.2 by adding an additional allow-rule in the patched policy sources.

Changes:

• Refreshes the patch header/summary metadata (commit SHA + insertion counts) for 0001-Flatcar-modifications.patch.
• Adds an SELinux policy allow-rule granting kernel_t the process execmem permission to avoid the reported Calico denial.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[chewi]

Yeah, that was my thinking even before I saw Copilot's message.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (1)

sdk_container/src/third_party/coreos-overlay/coreos/user-patches/sec-policy/flatcar-selinux-patches/0001-Flatcar-modifications.patch:310

• allow kernel_t self:process { execmem }; is a high-impact permission (W+X mappings) granted to all processes in kernel_t. Since this is being added to address a Calico-specific denial, it would help to (a) reference the upstream issue and (b) explicitly note why kernel_t is the right domain here (vs fixing the labeling/transition), so future policy tightening doesn’t accidentally depend on this broad allowance.

+#
+# This one happens in kubeadm.*.calico*.
+#
+# avc: denied { execmem } for  pid=2873 comm="calico-node" scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=process permissive=0
+allow kernel_t self:process { execmem };

[Copilot]

Pull request overview

Copilot reviewed 1 out of 3 changed files in this pull request and generated 2 comments.

Suppressed comments (1)

sdk_container/src/third_party/coreos-overlay/coreos/user-patches/sec-policy/flatcar-selinux-patches/0001-Flatcar-modifications.patch:310

• Granting execmem to kernel_t is a very broad relaxation (it effectively disables W^X-style protection for any process running in kernel_t). If this is truly needed for Calico, it would help to reference the upstream issue/version and ideally constrain the permission (e.g., via a tunable/conditional or by fixing the labeling so calico-node isn’t running in kernel_t).

+# FLATCAR:
+#
+# This one happens in kubeadm.*.calico*.
+#
+# avc: denied { execmem } for  pid=2873 comm="calico-node" scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=process permissive=0
+allow kernel_t self:process { execmem };

[Copilot]

Pull request overview

Copilot reviewed 2 out of 4 changed files in this pull request and generated no new comments.

Suppressed comments (2)

sdk_container/src/third_party/coreos-overlay/coreos/user-patches/sec-policy/flatcar-selinux-patches/README.md:14

• The README’s “Generate the patch” step was truncated; it no longer explains how to produce a correctly prefixed patch (the --src-prefix/--dst-prefix detail matters for these refpolicy patches). This makes the workflow hard to reproduce for future updates.

- Generate the patch

sdk_container/src/third_party/coreos-overlay/coreos/user-patches/sec-policy/flatcar-selinux-patches/0001-Flatcar-modifications.patch:310

• Granting execmem to kernel_t is a very broad permission (it weakens W^X for a highly privileged domain). If this is strictly needed for Calico 3.32.2’s calico-node on Flatcar, consider whether the process can be transitioned into a more specific domain (or a dedicated policy type) and allow execmem there instead. At minimum, it would be good to document why calico-node is running as kernel_t and link the upstream report for future audits.

+#
+# This one happens in kubeadm.*.calico*.
+#
+# avc: denied { execmem } for  pid=2873 comm="calico-node" scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=process permissive=0
+allow kernel_t self:process { execmem };