You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Supported OCI/runc binding for process-wide KILL on unknown syscalls and disallowed ABIs
#5558
We are evaluating a fail-closed seccomp policy for a Linux x86_64 offline test workload and would like to confirm the supported OCI/runc contract before attempting implementation.
Our static source review uses Docker/Moby 28.0.4 → runc 1.2.6 (commit e89a29929c775025419ab0d218a43588b4c12b9a) as reference versions, with a limited comparison against runc 1.5.2 (commit 29dd3dc2b13b4123162e5fe132504bb4b15569f1). These are source references, not claims about deployed binaries.
The intended OCI policy is native-only AMD64 with defaultAction=SCMP_ACT_KILL_PROCESS, no defaultErrnoRet, and a finite allowlist. Our static review indicates that InitSeccomp → PatchAndLoad may prepend an ENOSYS-returning branch for syscall numbers above the maximum resolved rule number; the libseccomp bad-architecture action is independently controlled and may default to thread kill rather than process kill. No container, filter, or test has been executed for this policy.
Question
Is there a documented, released OCI/runc interface usable through Docker that guarantees SCMP_ACT_KILL_PROCESS for every disallowed syscall (including arbitrary high/unknown numbers) and disallowed x32/i386/unknown architectures from the first runtime-installed filter, before the initial workload exec, without a permissive default, defaultErrnoRet tricks, synthetic syscall/threshold rules, custom runtime patches, or a later bootstrap-only guard?
If so, could you point us to the exact release, documentation, and supported settings binding both syscall-default and bad-arch actions?
If no such interface exists today, could you confirm that limitation so we do not mistake nominal defaultAction for an effective fail-stop guarantee? Relevant upstream discussions
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
We are evaluating a fail-closed seccomp policy for a Linux x86_64 offline test workload and would like to confirm the supported OCI/runc contract before attempting implementation.
Our static source review uses Docker/Moby 28.0.4 → runc 1.2.6 (commit
e89a29929c775025419ab0d218a43588b4c12b9a) as reference versions, with a limited comparison against runc 1.5.2 (commit29dd3dc2b13b4123162e5fe132504bb4b15569f1). These are source references, not claims about deployed binaries.The intended OCI policy is native-only AMD64 with
defaultAction=SCMP_ACT_KILL_PROCESS, nodefaultErrnoRet, and a finite allowlist. Our static review indicates thatInitSeccomp → PatchAndLoadmay prepend an ENOSYS-returning branch for syscall numbers above the maximum resolved rule number; the libseccomp bad-architecture action is independently controlled and may default to thread kill rather than process kill. No container, filter, or test has been executed for this policy.Question
Is there a documented, released OCI/runc interface usable through Docker that guarantees
SCMP_ACT_KILL_PROCESSfor every disallowed syscall (including arbitrary high/unknown numbers) and disallowed x32/i386/unknown architectures from the first runtime-installed filter, before the initial workload exec, without a permissive default,defaultErrnoRettricks, synthetic syscall/threshold rules, custom runtime patches, or a later bootstrap-only guard?If so, could you point us to the exact release, documentation, and supported settings binding both syscall-default and bad-arch actions?
If no such interface exists today, could you confirm that limitation so we do not mistake nominal
defaultActionfor an effective fail-stop guarantee?Relevant upstream discussions
Relevant upstream discussions
All reactions