| Package | Affected versions | Patched versions |
|---|---|---|
| github.com/fission/fission | < 1.25.0 | 1.25.0 |
Fission v1.24.0 added PodSpec safety validation for tenant-facing Environment and Function CRDs (ValidatePodSpecSafety / ValidateContainerSafety admission webhook + sanitizeContainerSecurityContext executor merge layer), but the
capability check was implemented as a fixed denylist of six Linux capabilities (SYS_ADMIN, NET_ADMIN, SYS_PTRACE, SYS_MODULE, DAC_READ_SEARCH, DAC_OVERRIDE). The denylist omitted CAP_SYS_TIME, among others. As a result, a tenant
who could create a Function or Environment CRD could request securityContext.capabilities.add: ["SYS_TIME"], pass Fission's admission validation and merge-layer sanitization, and run attacker-controlled code with CAP_SYS_TIME in the
resulting function or runtime container.
Demonstrated consequence: cross-tenant node integrity damage via CAP_SYS_TIME. The Linux real-time clock is not namespaced — time namespaces virtualize only MONOTONIC and BOOTTIME, never REALTIME — so a tenant container holding
CAP_SYS_TIME could call clock_settime(CLOCK_REALTIME) and rewrite the shared node wall clock. That corrupts TLS / certificate validity windows, Kubernetes lease renewal, token expiry, scheduling, and time-series for every workload on
the node.
The denylist also omitted SYS_RAWIO, BPF, SYS_RESOURCE, and MAC_ADMIN. Those are documented as evidence that the denylist is structurally incomplete (their practical impact is kernel-, LSM-, or device-cgroup-dependent and is not
exercised in this report).
The deeper structural problem: a denylist on capabilities.add cannot constrain capabilities the OCI runtime grants by default — DAC_OVERRIDE is in the OCI default cap set and reaches the container regardless of any add check,
partially mooting the denylist for its own entries. A capability allowlist (with drop:["ALL"] to remove the default set) is the only model that addresses both problems.
github.com/fission/fission<= 1.24.0ce617120) and current HEAD at audit timepkg/apis/core/v1/podspec_safety.go (dangerousCapabilities) and pkg/executor/util/merge.go (dangerousMergeContainerCapabilities)Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site freerestrictedFix section (paste into the Fix / Patches field)
Fixed in v1.25.0 by:
2569b42b) — replace the denylist with a PSA-restricted allowlist (NET_BIND_SERVICE only) at both enforcement
layers:
pkg/apis/core/v1/podspec_safety.go — ValidateContainerSafety now rejects any capabilities.add entry not in allowedCapabilities. The container check is invoked from ValidatePodSpecSafety for every PodSpec container /
init-container and from Environment.validateForAdmission for the bare Runtime.Container / Builder.Container.pkg/executor/util/merge.go — sanitizeContainerSecurityContext filters capabilities.add through the same allowlist at every merge site (poolmgr / newdeploy / container executor / builder).XValidation rules covering the cheap pod-level invariants (hostNetwork / hostPID / hostIPC / serviceAccountName / serviceAccount override) on FunctionSpec, Runtime, and Builder, plus
the bare-Container SecurityContext checks (privileged != true, allowPrivilegeEscalation != true, capabilities.add ⊆ {NET_BIND_SERVICE}) on Runtime and Builder. The API server now short-circuits those attack vectors per CRD
apply before the webhook is invoked. Per-container PodSpec iteration stays in the webhook because it exceeds the API server's CEL cost budget.pkg/apis/core/v1/podspec_safety_test.go:
TestAllTenantContainerSurfacesAreValidated walks every CRD root type via reflection and fails if any reachable *apiv1.PodSpec or *apiv1.Container field is missing from the hand-maintained known-covered set.TestTenantContainerSurfaces_RejectSysAdmin end-to-end exercises each covered surface and asserts ValidateForAdmission rejects a SYS_ADMIN injection at that exact path.The advisory's structural recommendation to force capabilities.drop: ["ALL"] at the merge layer is not part of this fix. Fission's own sidecar containers (fission-fetcher, builder) were authored against the OCI default capability
set and need a per-container cap audit before drop:["ALL"] can be applied uniformly. The allowlist on capabilities.add closes the demonstrated CAP_SYS_TIME impact; the OCI-default-cap concern (which the advisory itself marks as
conditional / not demonstrated) is tracked separately.