Skip to content

fix: allow CNI SELinux runtime operations#13625

Open
howdude230 wants to merge 1 commit into
siderolabs:release-1.13from
howdude230:howdude230/v1.13-selinux-cni-bpf-policy
Open

fix: allow CNI SELinux runtime operations#13625
howdude230 wants to merge 1 commit into
siderolabs:release-1.13from
howdude230:howdude230/v1.13-selinux-cni-bpf-policy

Conversation

@howdude230

Copy link
Copy Markdown

What

Allow SELinux policy operations needed by CNI agents and pod container runtime helpers on Talos 1.13:

  • BPF filesystem/file/dir writes from pod domains.
  • CNI state writes from pod domains.
  • pod containerd to pod unix stream socket connectto.
  • pod relabel operations on pod containerd runtime files.
  • bounded CNI/initramfs/udev startup operations observed while CNI plugins and module helpers run.
  • bounded read-only access for host diagnostics surfaces that expose process/rootfs/udev labels.

The generated embedded policy.33 is regenerated from the updated CIL sources.

Why

With SELinux enabled in permissive mode on Talos v1.13.4, Cilium/Multus-style networking can emit AVCs for legitimate CNI/BPF/runtime operations. Several of the needed rules already existed as commented Cilium/CNI policy hints; this makes those paths explicit and adds the missing bounded startup/read cases.

Validation

  • git diff --check
  • docker build --target selinux-generate --build-arg TOOLS_PREFIX=ghcr.io/siderolabs/tools --build-arg TOOLS=v1.13.0-4-ga06bb31 -o /tmp/talos-policy .
  • Verified internal/pkg/selinux/policy/policy.33 matches the regenerated policy output.

@github-project-automation github-project-automation Bot moved this to To Do in Planning Jun 20, 2026
@talos-bot talos-bot moved this from To Do to In Review in Planning Jun 20, 2026
@howdude230
howdude230 force-pushed the howdude230/v1.13-selinux-cni-bpf-policy branch 2 times, most recently from c46f8fa to 59b15e0 Compare June 20, 2026 22:54
Allow pod domains to perform CNI/BPF operations currently required by Cilium/Multus-style networking, including BPF filesystem writes, CNI state access, CNI socket connectto, and bounded runtime relabel/read cases. Also allow initramfs/udev startup handoff operations observed during CNI/plugin execution.

Signed-off-by: howdude230 <47754786+howdude230@users.noreply.github.com>
@howdude230
howdude230 force-pushed the howdude230/v1.13-selinux-cni-bpf-policy branch from 59b15e0 to c68abb9 Compare June 20, 2026 23:10
@frezbo
frezbo requested review from Copilot and dsseng June 21, 2026 05:30

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR updates Talos’s SELinux CIL policy sources to permit additional CNI/BPF/container-runtime operations in Talos 1.13 environments, reducing legitimate AVC denials for common Kubernetes networking and runtime workflows.

Changes:

  • Extend early-boot allowances (initramfs/udev) for executing helper binaries and using passed file descriptors.
  • Permit pod domains to perform additional containerd/CNI operations (CNI state writes, unix socket connectto, BPF prog_run, bounded diagnostics reads).
  • Allow pod relabel operations on pod containerd runtime files and enable BPF filesystem RW access (currently via any_p).

Reviewed changes

Copilot reviewed 4 out of 5 changed files in this pull request and generated 1 comment.

File Description
internal/pkg/selinux/policy/selinux/services/udev.cil Adds an initramfs fd-use permission for udev.
internal/pkg/selinux/policy/selinux/services/machined.cil Expands initramfs execute permissions for init/CNI/modprobe helpers.
internal/pkg/selinux/policy/selinux/services/cri.cil Grants pod domains additional CNI state/BPF/diagnostic access and enables pod-containerd connectto pod domains.
internal/pkg/selinux/policy/selinux/common/processes.cil Enables BPF filesystem RW access and adds pod relabel permissions for pod-containerd runtime files.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

; ; cilium-agent
; (allow any_p self (perf_event (all)))
; (allow any_p bpf_t (fs_classes (rw)))
(allow any_p bpf_t (fs_classes (rw)))

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes sense. Maybe we should even consider creating a separate context for bpf-capable pods and assign it to cilium-agent via its daemonset.

@dsseng dsseng left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your PR, could you please attach more logs for some insights on the new rules?

Comment on lines +97 to +103
(allow initramfs_t bin_exec_t (file (execute execute_no_trans)))
(allow initramfs_t init_exec_t (fs_classes (ro)))
(allow initramfs_t init_exec_t (file (execute)))
(allow initramfs_t cni_plugin_t (fs_classes (ro)))
(allow initramfs_t cni_plugin_t (file (execute execute_no_trans)))
(allow initramfs_t modprobe_exec_t (fs_classes (ro)))
(allow initramfs_t modprobe_exec_t (file (execute execute_no_trans)))

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please attach the AVC logs of these events (without this patch applied)?

Does the test build contain any extensions (or merely built via Factory)? If so, please rebuild using only the tooling in Talos repo.

I am currently tracking a bug which causes many denials to initramfs_t, while no process actually runs with this label. This bug is somehow bound to overlayfs created when working with system extensions, including a metadata one embedded by Image Factory, but has not yet been tracked down to the exact cause

(allow udev_t bin_exec_t (file (execute execute_no_trans)))
(allow udev_t kernel_t (system (ipc_info)))
(allow udev_t any_p (sem (all)))
(allow udev_t initramfs_t (fd (use)))

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, might stem from the same bug, so please attach a log. We should not work around this bug, as it will create a lot of wrong rules in the policy


; Host diagnostics mounted into pods can expose proc entries labelled with the
; owning process domain instead of procfs_t.
(allow pod_p init_t (file (getattr open read)))

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Curious what these are. But given it is effectively RO access to machined procfs, should be relatively harmless

Also wondering how is this going to coexist with #13615 - perhaps we will have to make Cilium not try to contact init anyway (or it will read from a stub one)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I saw this too just run ps aux from a kubectl debug pod with enforcing=1

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but I believe most workloads should be okay not examining host processes. And even if SELinux now allows that, namespace isolation would likely prevent them from seeing what they need, so I'm curious why do they need that

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was just pointing out something i observed, it's intended behavior and I don't see why we should allow it now

; ; cilium-agent
; (allow any_p self (perf_event (all)))
; (allow any_p bpf_t (fs_classes (rw)))
(allow any_p bpf_t (fs_classes (rw)))

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes sense. Maybe we should even consider creating a separate context for bpf-capable pods and assign it to cilium-agent via its daemonset.


; /run/flannel, created by containerd
(allow any_p pod_containerd_run_t (fs_classes (rw)))
(allow pod_p pod_containerd_run_t (fs_classes (relabelfrom relabelto)))

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the cause for this? But generally should be okay

@smira smira moved this from In Review to On Hold in Planning Jul 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: On Hold

Development

Successfully merging this pull request may close these issues.

6 participants