[19.03 backport] seccomp profile updates #41381
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
All clone flags for namespace should be denied. Based-on-patch-by: Kenta Tada <[email protected]> Signed-off-by: Sebastiaan van Stijn <[email protected]> (cherry picked from commit a1ec855) Signed-off-by: Sebastiaan van Stijn <[email protected]>
json files should not be executable I think. Signed-off-by: Arnaud Rebillout <[email protected]> (cherry picked from commit 667c87e) Signed-off-by: Sebastiaan van Stijn <[email protected]>
Add the membarrier syscall to the default seccomp profile. It is for example used in the implementation of dlopen() in the musl libc of Alpine images. Signed-off-by: Julio Guerra <[email protected]> (cherry picked from commit 1026f87) Signed-off-by: Sebastiaan van Stijn <[email protected]>
This only allows making the syscall. CAP_SYS_TIME is still required
for time adjustment (enforced by the kernel):
```
kernel/time/posix-timers.c:
1112 SYSCALL_DEFINE2(clock_adjtime, const clockid_t, which_clock,
1113 struct __kernel_timex __user *, utx)
...
1121 err = do_clock_adjtime(which_clock, &ktx);
1100 int do_clock_adjtime(const clockid_t which_clock, struct __kernel_timex * ktx)
1101 {
...
1109 return kc->clock_adj(which_clock, ktx);
1299 static const struct k_clock clock_realtime = {
...
1304 .clock_adj = posix_clock_realtime_adj,
188 static int posix_clock_realtime_adj(const clockid_t which_clock,
189 struct __kernel_timex *t)
190 {
191 return do_adjtimex(t);
kernel/time/timekeeping.c:
2312 int do_adjtimex(struct __kernel_timex *txc)
2313 {
...
2321 /* Validate the data before disabling interrupts */
2322 ret = timekeeping_validate_timex(txc);
2246 static int timekeeping_validate_timex(const struct __kernel_timex *txc)
2247 {
2248 if (txc->modes & ADJ_ADJTIME) {
...
2252 if (!(txc->modes & ADJ_OFFSET_READONLY) &&
2253 !capable(CAP_SYS_TIME))
2254 return -EPERM;
2255 } else {
2256 /* In order to modify anything, you gotta be super-user! */
2257 if (txc->modes && !capable(CAP_SYS_TIME))
2258 return -EPERM;
```
Fixes: moby#40919
Signed-off-by: Stanislav Levin <[email protected]>
(cherry picked from commit 5d3a9e4)
Signed-off-by: Sebastiaan van Stijn <[email protected]>
Restartable Sequences (rseq) are a kernel-based mechanism for fast update operations on per-core data in user-space. Some libraries, like the newest version of Google's TCMalloc, depend on it [1]. This also makes dockers default seccomp profile on par with systemd's, which enabled 'rseq' in early 2019 [2]. 1: https://google.github.io/tcmalloc/design.html 2: systemd/systemd@6fee3be Signed-off-by: Florian Schmaus <[email protected]> (cherry picked from commit d0d99b0) Signed-off-by: Sebastiaan van Stijn <[email protected]>
follow up to moby#41344 (comment) Signed-off-by: Jintao Zhang <[email protected]> (cherry picked from commit b8988c8) Signed-off-by: Sebastiaan van Stijn <[email protected]>
Signed-off-by: Jintao Zhang <[email protected]> (cherry picked from commit a181391) Signed-off-by: Sebastiaan van Stijn <[email protected]>
AkihiroSuda
approved these changes
Aug 24, 2020
|
The next release of Alpine Linux includes musl 1.2.2 with faccessat2. Several users have reported issues running make, since it calls eaccess, which musl implements correctly with faccessat2 (glibc instead emulates it, providing inaccurate results). Therefore, we and our users would highly appreciate it if at least the faccessat2 part of this PR could be expedited. Thank you. |
Member
Author
|
@Hello71 this is a backport for the orevious release, but these changes are already included in the current docker version (20.10) |
|
yes, I understand. however, many distros and users are still on 19.03, and it would be preferable if we could tell them to upgrade to 19.03.16+ instead of 20.10. |
|
if you want more information on alpine issues and our recommendations for docker users, see https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.13.0 and https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.14.0. |
yan12125
added a commit
to lxqt/lxqt-panel
that referenced
this pull request
Feb 10, 2021
Since glibc 2.33, the faccessat() function tries faccessat2 system call first and falls back to faccessat system call on older kernels [1]. However, seccomp profile provided by the Docker engine does not allow faccessat2 (fixed by [2][3]). As a result, faccessat2 returns EPERM, and glibc returns an error in this case. Using a patched glibc to work around this issue. Note that the aforementioned glibc patch does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
yan12125
added a commit
to lxqt/lxqt-panel
that referenced
this pull request
Feb 10, 2021
Since glibc 2.33, the faccessat() function tries faccessat2 system call first and falls back to faccessat system call on older kernels [1]. However, seccomp profile provided by the Docker engine does not allow faccessat2 (fixed by [2][3]). As a result, faccessat2 returns EPERM, and glibc returns an error in this case. Using a patched glibc to work around this issue. Note that the aforementioned glibc patch does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
yan12125
added a commit
to lxqt/lxqt-panel
that referenced
this pull request
Feb 10, 2021
Since glibc 2.33, the faccessat() function tries the faccessat2 system call first and falls back to the faccessat system call on older kernels [1]. However, the seccomp profile provided by old Docker engines does not allow faccessat2 (fixed by [2][3]). As a result, the faccessat2 system call returns EPERM, and glibc returns an error in this case. Using a patched glibc to workaround this issue. Note that the aforementioned glibc commit does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
yan12125
added a commit
to lxqt/lxqt-panel
that referenced
this pull request
Feb 10, 2021
Since glibc 2.33, the faccessat() function tries the faccessat2 system call first and falls back to the faccessat system call on older kernels [1]. However, the seccomp profile provided by old Docker engines does not allow faccessat2 (fixed by [2][3]). As a result, the faccessat2 system call returns EPERM, and glibc returns an error in this case. Using a patched glibc to workaround this issue. Note that the aforementioned glibc commit does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
atomlong
pushed a commit
to atomlong/run-on-arch-action
that referenced
this pull request
Mar 1, 2021
Since glibc 2.33, the faccessat() function tries the faccessat2 system call first and falls back to the faccessat system call on older kernels [1]. However, the seccomp profile provided by old Docker engines does not allow faccessat2 (fixed by [2][3]). As a result, the faccessat2 system call returns EPERM, and glibc returns an error in this case. Using a patched glibc to workaround this issue. Note that the aforementioned glibc commit does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
atomlong
pushed a commit
to atomlong/run-on-arch-action
that referenced
this pull request
Mar 1, 2021
Since glibc 2.33, the faccessat() function tries the faccessat2 system call first and falls back to the faccessat system call on older kernels [1]. However, the seccomp profile provided by old Docker engines does not allow faccessat2 (fixed by [2][3]). As a result, the faccessat2 system call returns EPERM, and glibc returns an error in this case. Using a patched glibc to workaround this issue. Note that the aforementioned glibc commit does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
atomlong
pushed a commit
to atomlong/run-on-arch-action
that referenced
this pull request
Mar 1, 2021
Since glibc 2.33, the faccessat() function tries the faccessat2 system call first and falls back to the faccessat system call on older kernels [1]. However, the seccomp profile provided by old Docker engines does not allow faccessat2 (fixed by [2][3]). As a result, the faccessat2 system call returns EPERM, and glibc returns an error in this case. Using a patched glibc to workaround this issue. Note that the aforementioned glibc commit does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
atomlong
pushed a commit
to atomlong/run-on-arch-action
that referenced
this pull request
Mar 1, 2021
Since glibc 2.33, the faccessat() function tries the faccessat2 system call first and falls back to the faccessat system call on older kernels [1]. However, the seccomp profile provided by old Docker engines does not allow faccessat2 (fixed by [2][3]). As a result, the faccessat2 system call returns EPERM, and glibc returns an error in this case. Using a patched glibc to workaround this issue. Note that the aforementioned glibc commit does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
atomlong
pushed a commit
to atomlong/run-on-arch-action
that referenced
this pull request
Mar 1, 2021
Since glibc 2.33, the faccessat() function tries the faccessat2 system call first and falls back to the faccessat system call on older kernels [1]. However, the seccomp profile provided by old Docker engines does not allow faccessat2 (fixed by [2][3]). As a result, the faccessat2 system call returns EPERM, and glibc returns an error in this case. Using a patched glibc to workaround this issue. Note that the aforementioned glibc commit does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
atomlong
pushed a commit
to atomlong/run-on-arch-action
that referenced
this pull request
Mar 1, 2021
Since glibc 2.33, the faccessat() function tries the faccessat2 system call first and falls back to the faccessat system call on older kernels [1]. However, the seccomp profile provided by old Docker engines does not allow faccessat2 (fixed by [2][3]). As a result, the faccessat2 system call returns EPERM, and glibc returns an error in this case. Using a patched glibc to workaround this issue. Note that the aforementioned glibc commit does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
atomlong
pushed a commit
to atomlong/run-on-arch-action
that referenced
this pull request
Mar 1, 2021
Since glibc 2.33, the faccessat() function tries the faccessat2 system call first and falls back to the faccessat system call on older kernels [1]. However, the seccomp profile provided by old Docker engines does not allow faccessat2 (fixed by [2][3]). As a result, the faccessat2 system call returns EPERM, and glibc returns an error in this case. Using a patched glibc to workaround this issue. Note that the aforementioned glibc commit does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
atomlong
pushed a commit
to atomlong/run-on-arch-action
that referenced
this pull request
Mar 1, 2021
Since glibc 2.33, the faccessat() function tries the faccessat2 system call first and falls back to the faccessat system call on older kernels [1]. However, the seccomp profile provided by old Docker engines does not allow faccessat2 (fixed by [2][3]). As a result, the faccessat2 system call returns EPERM, and glibc returns an error in this case. Using a patched glibc to workaround this issue. Note that the aforementioned glibc commit does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
atomlong
pushed a commit
to atomlong/run-on-arch-action
that referenced
this pull request
Apr 3, 2021
Since glibc 2.33, the faccessat() function tries the faccessat2 system call first and falls back to the faccessat system call on older kernels [1]. However, the seccomp profile provided by old Docker engines does not allow faccessat2 (fixed by [2][3]). As a result, the faccessat2 system call returns EPERM, and glibc returns an error in this case. Using a patched glibc to workaround this issue. Note that the aforementioned glibc commit does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
atomlong
pushed a commit
to atomlong/run-on-arch-action
that referenced
this pull request
Apr 3, 2021
Since glibc 2.33, the faccessat() function tries the faccessat2 system call first and falls back to the faccessat system call on older kernels [1]. However, the seccomp profile provided by old Docker engines does not allow faccessat2 (fixed by [2][3]). As a result, the faccessat2 system call returns EPERM, and glibc returns an error in this case. Using a patched glibc to workaround this issue. Note that the aforementioned glibc commit does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
atomlong
pushed a commit
to atomlong/run-on-arch-action
that referenced
this pull request
Apr 7, 2021
Since glibc 2.33, the faccessat() function tries the faccessat2 system call first and falls back to the faccessat system call on older kernels [1]. However, the seccomp profile provided by old Docker engines does not allow faccessat2 (fixed by [2][3]). As a result, the faccessat2 system call returns EPERM, and glibc returns an error in this case. Using a patched glibc to workaround this issue. Note that the aforementioned glibc commit does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
atomlong
pushed a commit
to atomlong/run-on-arch-action
that referenced
this pull request
Apr 10, 2021
Since glibc 2.33, the faccessat() function tries the faccessat2 system call first and falls back to the faccessat system call on older kernels [1]. However, the seccomp profile provided by old Docker engines does not allow faccessat2 (fixed by [2][3]). As a result, the faccessat2 system call returns EPERM, and glibc returns an error in this case. Using a patched glibc to workaround this issue. Note that the aforementioned glibc commit does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
atomlong
pushed a commit
to atomlong/run-on-arch-action
that referenced
this pull request
Apr 18, 2021
Since glibc 2.33, the faccessat() function tries the faccessat2 system call first and falls back to the faccessat system call on older kernels [1]. However, the seccomp profile provided by old Docker engines does not allow faccessat2 (fixed by [2][3]). As a result, the faccessat2 system call returns EPERM, and glibc returns an error in this case. Using a patched glibc to workaround this issue. Note that the aforementioned glibc commit does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
atomlong
pushed a commit
to atomlong/run-on-arch-action
that referenced
this pull request
Apr 19, 2021
Since glibc 2.33, the faccessat() function tries the faccessat2 system call first and falls back to the faccessat system call on older kernels [1]. However, the seccomp profile provided by old Docker engines does not allow faccessat2 (fixed by [2][3]). As a result, the faccessat2 system call returns EPERM, and glibc returns an error in this case. Using a patched glibc to workaround this issue. Note that the aforementioned glibc commit does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
atomlong
pushed a commit
to atomlong/run-on-arch-action
that referenced
this pull request
Apr 19, 2021
Since glibc 2.33, the faccessat() function tries the faccessat2 system call first and falls back to the faccessat system call on older kernels [1]. However, the seccomp profile provided by old Docker engines does not allow faccessat2 (fixed by [2][3]). As a result, the faccessat2 system call returns EPERM, and glibc returns an error in this case. Using a patched glibc to workaround this issue. Note that the aforementioned glibc commit does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
atomlong
pushed a commit
to atomlong/run-on-arch-action
that referenced
this pull request
Apr 19, 2021
Since glibc 2.33, the faccessat() function tries the faccessat2 system call first and falls back to the faccessat system call on older kernels [1]. However, the seccomp profile provided by old Docker engines does not allow faccessat2 (fixed by [2][3]). As a result, the faccessat2 system call returns EPERM, and glibc returns an error in this case. Using a patched glibc to workaround this issue. Note that the aforementioned glibc commit does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
atomlong
pushed a commit
to atomlong/run-on-arch-action
that referenced
this pull request
Apr 19, 2021
Since glibc 2.33, the faccessat() function tries the faccessat2 system call first and falls back to the faccessat system call on older kernels [1]. However, the seccomp profile provided by old Docker engines does not allow faccessat2 (fixed by [2][3]). As a result, the faccessat2 system call returns EPERM, and glibc returns an error in this case. Using a patched glibc to workaround this issue. Note that the aforementioned glibc commit does not mean that glibc 2.33 building on new kernels does not work with old kernels. Instead, the __LINUX_KERNEL_VERSION macro is 0 by default to achieve best-effort compatibility with various kernel versions. [1] https://sourceware.org/git/?p=glibc.git;a=patch;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2 [2] moby/moby#41353 [3] moby/moby#41381
|
We just ran into this issue. Can these changes be merged soon with a 19.03.16 tag? |
Member
Author
|
There are currently no plans to do additional 19.03 releases; if possible, I'd recommend upgrading to 20.10, but if you need the updated profile, you can download the JSON version (from the master branch, or from a specific tag; e.g. https://raw.githubusercontent.com/moby/moby/v20.10.7/profiles/seccomp/default.json, and configure your daemon to use that profile as default in the daemon configuration ( |
Member
Author
|
I'm closing this PR, as 19.03 has not been maintained for 2 Years, and there are no plans for more 19.03.x patch releases. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backports of:
clock_adjtime#40929 seccomp: Whitelistclock_adjtimeclock_adjtimeunder CAP_SYS_TIME #40919