fix: allow CNI SELinux runtime operations#13625
Conversation
c46f8fa to
59b15e0
Compare
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>
59b15e0 to
c68abb9
Compare
There was a problem hiding this comment.
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, BPFprog_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))) |
There was a problem hiding this comment.
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
left a comment
There was a problem hiding this comment.
Thanks for your PR, could you please attach more logs for some insights on the new rules?
| (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))) |
There was a problem hiding this comment.
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))) |
There was a problem hiding this comment.
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))) |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
I saw this too just run ps aux from a kubectl debug pod with enforcing=1
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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))) |
There was a problem hiding this comment.
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))) |
There was a problem hiding this comment.
What is the cause for this? But generally should be okay
What
Allow SELinux policy operations needed by CNI agents and pod container runtime helpers on Talos 1.13:
connectto.The generated embedded
policy.33is 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 --checkdocker build --target selinux-generate --build-arg TOOLS_PREFIX=ghcr.io/siderolabs/tools --build-arg TOOLS=v1.13.0-4-ga06bb31 -o /tmp/talos-policy .internal/pkg/selinux/policy/policy.33matches the regenerated policy output.