Fission: Incomplete capability denylist in Environment/Function PodSpec validation allows tenant-added CAP_SYS_TIME and cross-tenant node wall-clock corruption

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.

Affected

• Project: github.com/fission/fission
• Versions: <= 1.24.0
• Audited commits: v1.24.0 tag (ce617120) and current HEAD at audit time
• Component: pkg/apis/core/v1/podspec_safety.go (dangerousCapabilities) and pkg/executor/util/merge.go (dangerousMergeContainerCapabilities)
• Pre-condition: cluster does not enforce a restrictive Pod Security Admission (PSA) profile on the function-pod namespace. With PSA in force the API server's PodSecurity admission rejects the pod at creation and this finding does not apply. Fission added its own PodSpec validation precisely because it cannot assume PSA enforcement.