Skip to content

The C-0211 SELinux fill writes a bare level:s0, which would flatten runtime MCS categories on an SELinux nodeΒ #3477

Description

@devantler

πŸ€– Generated by the Agentic Engineer

Evidence

add-security-context supplies the C-0211 SELinux field by writing a literal level: s0 β€” at
container scope for pods that declare no pod-level SELinux object, and (as of #3460) at pod scope
where the pod-level object exists but carries no level.

On a SELinux-enforcing node the container runtime assigns each container its own MCS category pair,
producing a level such as s0:c12,c19. Those categories are what keep two containers on the same
node from reading each other's labelled files. Writing a bare, category-free s0 replaces the
runtime-assigned level, so every mutated container would share one level and lose that isolation.

Why this is not urgent, and not dismissable either

It is inert today: every node is Talos v1.13.9, which enforces AppArmor rather than SELinux, so
no MCS categories are being assigned for s0 to overwrite. Measured 2026-08-30 on oidc@prod: all
nodes report Talos (v1.13.9), and zero pods cluster-wide declare a pod-level seLinuxOptions.

But the policy presents the setting as defence-in-depth for SELinux nodes, which is precisely the
case where the current value would weaken isolation rather than add to it. So this is a latent
correctness gap that activates silently on a node-OS change β€” the kind that is cheap now and
expensive to discover later.

Affected audience and impact

Operators of any future SELinux-enforcing node pool in this cluster. Impact is a weakened
same-node isolation boundary between containers in the opted-in namespaces, with no signal that
anything changed.

Acceptance criteria

  • Decide the policy's behaviour on SELinux-enforcing nodes: either stop writing level where the
    runtime would assign one, narrow the mutation to node pools known not to enforce SELinux, or
    record an explicit accepted-risk with the reasoning in the policy itself.
  • Whichever path is chosen, the policy carries a comment stating what happens on an SELinux node,
    so the next reader does not have to re-derive it.
  • A test pins the chosen behaviour in both states.

Size

Small β€” a decision plus a scoped policy change and one fixture. The investigation is already done
here; what remains is the call and its coverage.

Raised from a Codex P2 review finding on #3460, where it was correctly judged real but out of scope
for that PR: fixing it there would have blocked a control that is currently unmet, to protect an
isolation property no node in this cluster currently provides.

Activity

  1. moved this to πŸ“₯ Backlog in 🌊 Project Boardon Aug 30, 2026
  2. devantler commented on Sep 6, 2026

    @devantler
    ContributorAuthor

    πŸ€– Generated by the Agentic Engineer

    The bare s0 is avoidable: C-0211 does not require level β€” measured

    This issue describes the gap exactly ("writing a bare, category-free s0 replaces the runtime-assigned level") and correctly calls it latent rather than urgent. What was missing was whether the control forces the trade-off. It does not.

    Six single-variable fixtures scanned offline (ksail workload scan --no-render --framework allcontrols; C-0211 is absent from the nsa,mitre pair CI runs):

    seLinuxOptions scope C-0211
    absent β€” failed ← control: the check is live
    {level: s0} pod / container passed
    {type: container_t} pod / container passed
    {user: system_u} pod passed
    {} pod + container passed

    Any non-absent object satisfies the control; only omitting the field fails. So the fix you describe β€” stop writing a category-free level β€” costs nothing in posture.

    Recorded as the decision on #3465 (option 2), with the rollout scope and its two open judgement calls on #3578.

  3. self-assigned this
    on Sep 6, 2026
  4. added a commit that references this issue on Sep 6, 2026
  5. moved this from πŸ“₯ Backlog to πŸƒπŸ»β€β™‚οΈ In Progress in 🌊 Project Boardon Sep 6, 2026
  6. added 2 commits that reference this issue on Sep 6, 2026
  7. moved this from πŸƒπŸ»β€β™‚οΈ In Progress to πŸ‘€ In Review in 🌊 Project Boardon Sep 6, 2026
  8. moved this from πŸ‘€ In Review to πŸƒπŸ»β€β™‚οΈ In Progress in 🌊 Project Boardon Sep 6, 2026
  9. moved this from πŸƒπŸ»β€β™‚οΈ In Progress to πŸš€ Ready to Merge in 🌊 Project Boardon Sep 6, 2026
  10. moved this from πŸš€ Ready to Merge to βœ… Done in 🌊 Project Boardon Sep 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Fields

No fields configured for Security.

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions