-
Notifications
You must be signed in to change notification settings - Fork 18.8k
profile/seccomp: Update to kernel v6.13 (libseccomp v2.6.0, containerd) #50077
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
reference: seccomp/libseccomp@f01e675 (libseccomp v2.6.0) containerd/containerd@6180d62 - v6.8: * listmount (torvalds/linux@b4c2bea) * lsm_get_self_attr, lsm_set_self_attrs (torvalds/linux@a04a119) * lsm_list_modules (torvalds/linux@ad4aff9) * statmount (torvalds/linux@46eae99) - v6.9: * mseal (torvalds/linux@8be7258) - v6.11: * uretprobe (torvalds/linux@190fec7) - v6.12: * riscv_hwprobe (torvalds/linux@3db80c9) Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
reference: seccomp/libseccomp@42b5968 (libseccomp v2.6.0) containerd/containerd@1a4c3210 - v6.13: * getxattrat, listxattrat, removexattrat, setxattrat (torvalds/linux@6140be9) Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
Update the default seccomp profile to include new syscalls introduced in kernel v6.8–v6.13 (libseccomp v2.6.0), preventing EPERM errors in containers.
- Added new syscalls (
listmount,getxattrat,mseal, etc.) to the Go default profile. - Mirrored the same syscall additions in the JSON default profile.
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| profiles/seccomp/default_linux.go | Inserted new syscalls matching kernel v6.8–v6.13 changes |
| profiles/seccomp/default.json | Added identical syscall entries to the JSON profile |
Comments suppressed due to low confidence (2)
profiles/seccomp/default_linux.go:169
- Consider adding or updating unit tests to assert that
DefaultProfile()includes the newly added syscallgetxattrat.
"getxattrat", // kernel v6.13, libseccomp v2.6.0
profiles/seccomp/default.json:177
- Add or update tests to verify that the JSON default profile includes the new
getxattratsyscall.
"getxattrat",
| "lsetxattr", | ||
| "lsm_get_self_attr", | ||
| "lsm_list_modules", | ||
| "lsm_set_self_attrs", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lsm_set_self_attr
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we sure this is a secure syscall?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, good catch! My upstream containerd doesn't have this error in code (but it does in the PR body), so I must have made a mistake when making this PR 🙈
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding is it safe - you can already do what this syscall does via userspace procfs /proc/self/attr/.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My upstream containerd doesn't have this error in code (but it does in the PR body), so I must have made a mistake when making this PR 🙈
Good catch indeed; I definitely missed it (but probably assumed this was a literal copy/paste from the containerd PR 😓)
you can already do what this syscall does via userspace procfs
/proc/self/attr/.
Curious (bear with me, I haven't read up what kind of things this would set); even though possible through /proc/self/attr, would allowing this syscall potentially mean that something in the container would do things that are not generally expected to be ran in a container? (And if so, would blocking by default be useful?); not from a security perspective, but more a "guardrails" perspective.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good point. Opened a PR to put them behind CAP_SYS_ADMIN: #50097
We can revisit this later

Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.

Update default seccomp profile to match libseccomp v2.6.0
seccomp: kernel v6.12
reference: seccomp/libseccomp@f01e675 (libseccomp v2.6.0)
v6.8:
v6.9:
v6.11:
v6.12:
seccomp: kernel v6.13
reference: seccomp/libseccomp@42b5968 (libseccomp v2.6.0)
- Human readable description for the release notes
- A picture of a cute animal (not mandatory but encouraged)