profiles: seccomp: update to Linux 5.11 syscall list#41889
profiles: seccomp: update to Linux 5.11 syscall list#41889AkihiroSuda merged 1 commit intomoby:masterfrom
Conversation
cyphar
force-pushed
the
seccomp-update
branch
from
7a22284 to
81972c9
Compare
|
I just noticed some other syscalls were missing (all of the v2 mount API syscalls, and |
|
opened containerd/containerd#4957 to make the same changes in the containerd seccomp profile |
These syscalls (some of which have been in Linux for a while but were missing from the profile) fall into a few buckets: * close_range(2), epoll_pwait2(2) are just extensions of existing "safe for everyone" syscalls. * The mountv2 API syscalls (fs*(2), move_mount(2), open_tree(2)) are all equivalent to aspects of mount(2) and thus go into the CAP_SYS_ADMIN category. * process_madvise(2) is similar to the other process_*(2) syscalls and thus goes in the CAP_SYS_PTRACE category. Signed-off-by: Aleksa Sarai <[email protected]>
|
I can't reproduce the test failure locally -- it might be a flaky test? |
cyphar
force-pushed
the
seccomp-update
branch
from
81972c9 to
54eff43
Compare
Yes, there's some oddness currently with the s390x and ppc64le nodes. s390x looks to be #41933, for ppc64le, and I'm hoping #41932 will improve ppc64le (or at least gives us more useful errors). Sorry this is taking long to get merged; while those failures are not related, I'd love to see CI pass for those architectures, just in case there's some issue with seccomp on them, so I've been kicking CI many times. Thanks for rebasing the PR, I was considering doing a rebase, to see if it helped (but didn't want to push to your branch); I'll check if the s390x issue was fixed, and continue trying 🤞 (might give you a ping to do a rebase after #41932 is merged) |
|
I mean there was a non s390x/ppc64le failure ( |
5 participants
These syscalls (some of which have been in Linux for a while but were
missing from the profile) fall into a few buckets:
close_range(2), epoll_wait2(2) are just extensions of existing "safe
for everyone" syscalls.
The mountv2 API syscalls (fs*(2), move_mount(2), open_tree(2)) are
all equivalent to aspects of mount(2) and thus go into the
CAP_SYS_ADMIN category.
process_madvise(2) is similar to the other process_*(2) syscalls and
thus goes in the CAP_SYS_PTRACE category.
Signed-off-by: Aleksa Sarai [email protected]