Runtime classes cannot bound privilege escalation or seccomp, only capabilities

[scotwells]

Summary

A customer can weaken two of the three confinement settings on a sandbox container to any value the API enum allows, and no runtime class can refuse it. Capabilities are bounded — a class publishes grantableCapabilities and a request beyond it is rejected with a reason naming the class. Privilege escalation and the seccomp profile have no equivalent published ceiling, so allowPrivilegeEscalation: true and seccompProfile: Unconfined are accepted by every class in service today.

Separately, a container that both adds and drops the same capability is stored as written instead of being refused or normalised.

This is not presently an exposure. Every runtime class in service is VM-isolated: each instance runs its own guest kernel, so these settings take effect inside the customer's own virtual machine and reach nothing shared. The gap is structural. A future class backed by shared-kernel isolation would inherit the same permissiveness silently, because the class contract has no way to state a limit and validation has nothing to reject against.

Follows #310, which introduced the published security context surface.

Evidence

Verified against the staging datum-cloud project control plane with kubectl apply --dry-run=server, on a sandbox Workload using class: general-purpose.

Input	Result	Stored as
allowPrivilegeEscalation: true	accepted, no warning	true
seccompProfile: {type: Unconfined}	accepted, no warning	Unconfined
capabilities: {add: [CHOWN], drop: [CHOWN]}	accepted	add: [CHOWN], drop: [CHOWN, ALL]

For contrast, an add beyond the class's grantable set is rejected naming the class and the set it grants.

The gap is deliberate and documented, not accidental. Capabilities are the only security setting checked against the class. A class publishes defaultSecurityContext values for allowPrivilegeEscalation and seccompProfile, and those are explicitly documented as a default rather than a limit — so whatever the container states for either is accepted. grantableCapabilities is the only ceiling the class contract expresses.

For the contradictory add/drop case, each capability name in add and drop is checked on its own and the two lists are never compared, so an overlap passes; ALL is then appended to drop, producing the stored value above.

The question is already recorded as an open question in the runtime classes enhancement, including the note that adding a limit later is a compatible change because it only narrows what is accepted. This issue tracks it as work rather than restating it.

Reproduction

Against a control plane with the RuntimeClasses gate enabled and the general-purpose class published:

apiVersion: compute.datumapis.com/v1alpha
kind: Workload
metadata:
  name: confinement-probe
spec:
  runtimeClass:
    class: general-purpose
  template:
    spec:
      runtime:
        sandbox:
          containers:
            - name: probe
              image: nginx:alpine
              securityContext:
                allowPrivilegeEscalation: true
                seccompProfile:
                  type: Unconfined
                capabilities:
                  add: [CHOWN]
                  drop: [CHOWN]
      placements:
        - name: default
          cityCodes: [DFW]

kubectl apply --dry-run=server -f probe.yaml -o yaml

The object is admitted and the values above are returned in the dry-run result.

Expected behaviour

For maintainers to decide: should a runtime class be able to bound privilege escalation and the seccomp profile the way it bounds capabilities, so a class can refuse a container that asks for less confinement than the class is willing to serve? If so, the class contract needs a published limit for each, and validation needs to reject against it.

The contradictory add/drop case is separable and smaller: a container that both adds and drops the same capability has stated something self-contradictory, and the API should refuse it or normalise it rather than store it.

[scotwells]

Recommendation: stage it, and key the limit on the isolation boundary rather than on new class fields

What customers see: nothing changes for any workload that exists or is created on a class we ship today. That only holds if the work is sequenced. The obvious design, where a class that says nothing refuses these settings, would refuse them straight away on unikernel, the default class most customers land on. It would also break workloads already stored with them. So the headline is: close the gap in the order below, and not with that design.

Why "a class that says nothing refuses" does not work

A per-class feature (declare privilegeEscalation / unconfinedSeccomp, refuse if absent) looks like it copies the capability grant. In practice it fails in four ways.

• It changes behaviour on the default tier. unikernel declares neither feature and has no published security context default. Only general-purpose uses this surface. Refusing by omission would reject both settings on the class most workloads use. It also asks a question that has no answer: a unikernel has no Linux syscall filter, so what would it mean to declare that it serves "unconfined seccomp"?
• It has an outage in both rollout directions. The class bodies customers see are hand-kept copies, maintained apart from the validation code in a different repository. Ship validation first and every affected request is refused. Ship the class bodies first and the catalog fails to publish, because the new feature name is not yet a known value, and a project with no catalog refuses every workload. This has already happened on this surface: a class copy fell behind its provider, and every capability request was refused until the copy caught up.
• It does not deliver the safety it promises. A feature declaration is an unchecked claim, typed into the same hand-kept file as the isolation boundary. Nothing checks that a provider honours a declared feature. This has already bitten: a provider declares a feature it does not actually implement, and the published class copy deliberately leaves that feature out because of it. The only thing keeping the two consistent was someone noticing. The class's availability status is a fixed assertion, not an observed signal. A shared-kernel tier could still ship permissive: someone would only have to add two lines. That is a tripwire, not a guarantee.
• It does not share the invariants it copies. The capability feature is tied to its data: grantable capabilities require the feature, the feature requires a non-empty grant, and a class's published default must fall within its grant. Two new features without equivalent rules would let a class publish a default that its own features refuse. Every workload on that class would then fail admission, citing a field the customer never wrote. The "same refusal message as an unsupported construct" benefit is also weaker than it looks. That message names an unsupported API construct, so refusing a value needs a second message form anyway.

Per-setting limit fields have the same rollout and self-assertion problems, plus three differently shaped ceilings on one class.

What to do instead, in order

1. Make "unchanged is acceptable" a platform rule first. This step comes first, whatever limit follows. A limit on a setting that is already accepted and stored must only apply when that setting changes. Otherwise a stored workload can no longer be updated, and so cannot be deleted either, because the platform's own cleanup update would be refused. The limit must also apply only when a customer submits a change, never when a provider renders an instance that is already running. Without this rule, any tightening turns into an outage for existing workloads.

2. Key the limit on the isolation boundary, and refuse unknown boundaries. The platform, not the class file, owns a short list of boundaries under which reduced confinement is acceptable. Both virtual-machine and unikernel are on it because each instance has its own kernel. A class whose boundary is not on the list refuses allowPrivilegeEscalation: true and seccompProfile: Unconfined, naming the class and its boundary.

A class that has never been reviewed therefore refuses by default. We get this without enumerating the boundary in the API, without new published fields, and without a catalog change. The boundary stays an open token, and a new tier is still not an API change. Only a new tier that wants reduced confinement needs a policy change. Because the list lives with the validation code, there is no two-repository ordering and no outage window. Both boundaries in service today are on the list from the first release.

This also gives the unikernel an honest answer. These settings are allowed there because nothing about them reaches beyond the instance's own kernel, not because the class claimed a feature.

3. Say plainly what this does not guarantee. A class could still claim virtual-machine for a tier that shares a kernel. The boundary is also typed by hand, so this is still a tripwire. It is a better one for two reasons:

• The lie would have to be in the one sentence customers read to decide how isolated they are. It would not be hidden in a feature list that someone extends to make a refusal go away.
• The deliberate step moves out of a document and into the platform. Admitting a new boundary to reduced confinement means changing a list that the validation code owns and that is reviewed with it.

That review is the real control, and the design should say so rather than claim that a mistake is impossible. The safeguard does not depend on someone remembering. A new boundary is refused until someone deliberately adds it, and adding it is the reviewed step.

4. Defer anything more expressive until a shared-kernel tier exists. Per-class limits, and a class honestly saying "I will run this but not that", become worth their API surface once there is a tier that needs them. They need an availability signal that observes the provider, not a fixed assertion. Adding them later only narrows what is accepted, so it stays a compatible change.

The contradictory add/drop case: do not refuse it

Refusing an overlap sounds tidy but breaks promises the API already makes:

• The security context is documented as mirroring the Kubernetes shape so existing manifests carry over, and drop is documented as accepted for compatibility. A manifest that applies and runs on Kubernetes would be rejected here.
• Templating layers routinely merge a hardened baseline drop with a per-service add, and the customer often cannot edit the generator.
• drop already has a published meaning for overlap: naming a capability there removes it even when the class would grant it. So letting drop win is not silently discarding part of the request. The field is doing what it says.
• Workloads are already stored in this shape. The platform wrote part of that shape itself by adding ALL to drop. Every stored container on general-purpose already lists capabilities in add and ALL in drop, which is the customer-readable form we chose. A rule that refuses it would block updates to those workloads.

Recommendation: accept it, let a named drop win, and return a non-blocking admission warning naming the capability. The customer learns something true about what they wrote, and nothing already stored gets stuck.

This has to agree with #312

Whatever resolves an overlap must match what the platform applies when it runs the container. Today a capability named in both lists is left out of the running container: drop wins at runtime.

An ordering of "class default, minus drops, plus adds" would make add win for a capability named in both lists. If the two issues settle differently, a stored workload will list a capability that its running container does not have. That is exactly the kind of misleading spec the stamped security context exists to prevent.

The rule that fits both issues:

• ALL in drop clears the class default, so drop: [ALL] plus add still means exactly the adds, as Adding one capability silently strips the runtime class defaults, breaking stock images #312 requires.
• A capability named in drop is removed even if it also appears in add.

#312 and this issue should adopt that single rule together, and the stored form and the running container should both follow it.