* [Buildroot] [PATCH] package/openssh: allow sandboxing to be disabled as workaround for seccomp issues @ 2022-09-18 13:30 Peter Korsgaard 2022-09-18 14:58 ` Yann E. MORIN 2022-09-29 14:05 ` Peter Korsgaard 0 siblings, 2 replies; 4+ messages in thread From: Peter Korsgaard @ 2022-09-18 13:30 UTC (permalink / raw) To: buildroot As explained in bug #14796, there are situations where the seccomp based sandboxing in openssh can get confused, leading to connection issues. As explained by Thomas in the bug report: glibc does not care about the kernel headers when deciding whether to try the clock_gettime64() syscall or not: it always use it, and if that fails at runtime, it falls back to clock_gettime(). This is how glibc ends up using clock_gettime64() even if your kernel does not support it. On the other hand, the OpenSSL seccomp code relies on kernel headers to decide whether the clock_gettime64() syscall should be in the allowed list of syscalls or not. So when you are in a situation where glibc is recent, but your kernel is older, you get into precisely the problem you have: glibc tries to use clock_gettime64, but OpenSSH seccomp configuration prevents that, which does not allow glibc to gracefully fallback to clock_gettime (as seccomp is configured to kill the process on filter violations). As a workaround, add a _OPENSSH_SANDBOX option (defaulting to y) to decide if sandboxing should be used or not. Fixes (works around) #14796 Signed-off-by: Peter Korsgaard <peter@korsgaard.com> --- package/openssh/Config.in | 8 ++++++++ package/openssh/openssh.mk | 1 + 2 files changed, 9 insertions(+) diff --git a/package/openssh/Config.in b/package/openssh/Config.in index cc5998742e..08d3c7d391 100644 --- a/package/openssh/Config.in +++ b/package/openssh/Config.in @@ -31,4 +31,12 @@ config BR2_PACKAGE_OPENSSH_KEY_UTILS help Key utilities: ssh-keygen, ssh-keyscan. +config BR2_PACKAGE_OPENSSH_SANDBOX + bool "use sandboxing" + default y + help + Use sandboxing for extra privilege protection of processes. + + This is normally preferable, but may cause seccomp problems + for certain combinations of C libraries and kernel versions. endif diff --git a/package/openssh/openssh.mk b/package/openssh/openssh.mk index 63a28f3af5..9fab2c9038 100644 --- a/package/openssh/openssh.mk +++ b/package/openssh/openssh.mk @@ -24,6 +24,7 @@ OPENSSH_CPE_ID_VENDOR = openbsd OPENSSH_CONF_OPTS = \ --sysconfdir=/etc/ssh \ --with-default-path=$(BR2_SYSTEM_DEFAULT_PATH) \ + $(if $(BR2_PACKAGE_OPENSSH_SANDBOX),--with-sandbox,--without-sandbox) \ --disable-lastlog \ --disable-utmp \ --disable-utmpx \ -- 2.30.2 _______________________________________________ buildroot mailing list buildroot@buildroot.org https://lists.buildroot.org/mailman/listinfo/buildroot ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [Buildroot] [PATCH] package/openssh: allow sandboxing to be disabled as workaround for seccomp issues 2022-09-18 13:30 [Buildroot] [PATCH] package/openssh: allow sandboxing to be disabled as workaround for seccomp issues Peter Korsgaard @ 2022-09-18 14:58 ` Yann E. MORIN 2022-09-18 15:45 ` Peter Korsgaard 2022-09-29 14:05 ` Peter Korsgaard 1 sibling, 1 reply; 4+ messages in thread From: Yann E. MORIN @ 2022-09-18 14:58 UTC (permalink / raw) To: Peter Korsgaard; +Cc: buildroot Peter, All, On 2022-09-18 15:30 +0200, Peter Korsgaard spake thusly: > As explained in bug #14796, there are situations where the seccomp based > sandboxing in openssh can get confused, leading to connection issues. [--SNIP--] > As a workaround, add a _OPENSSH_SANDBOX option (defaulting to y) to decide > if sandboxing should be used or not. [--SNIP--] > diff --git a/package/openssh/openssh.mk b/package/openssh/openssh.mk > index 63a28f3af5..9fab2c9038 100644 > --- a/package/openssh/openssh.mk > +++ b/package/openssh/openssh.mk > @@ -24,6 +24,7 @@ OPENSSH_CPE_ID_VENDOR = openbsd > OPENSSH_CONF_OPTS = \ > --sysconfdir=/etc/ssh \ > --with-default-path=$(BR2_SYSTEM_DEFAULT_PATH) \ > + $(if $(BR2_PACKAGE_OPENSSH_SANDBOX),--with-sandbox,--without-sandbox) \ --with-sandbox expects an argument that specifies what type of sandbox to use: --with-sandbox=style Specify privilege separation sandbox (no, capsicum, darwin, rlimit, seccomp_filter, systrace, pledge) If we just pass --with-sandbox without a value, configure will try to look for a list of available sabdboxing mechanisms, and use the first it finds: https://github.com/openssh/openssh-portable/blob/1875042c52a3b950ae5963c9ca3774a4cc7f0380/configure.ac#L3642 All that is before looks like it is BSD-only: pledge and systrace, or darwin. But then, after seccomp, there is also capsicum and rlimit. Capsicum on linux does not exist, and rlimit is probably does not bring much security-wise... So, in all practical matters, on Linux, sandboxing uses seccomp filtering, or there is no sandboxing. I've added a blurb to explain the above, and applied to master, thanks. Note that it looks like we can disable seccomp with: ac_cv_have_decl_SECCOMP_MODE_FILTER=no Regards, Yann E. MORIN. > --disable-lastlog \ > --disable-utmp \ > --disable-utmpx \ > -- > 2.30.2 > > _______________________________________________ > buildroot mailing list > buildroot@buildroot.org > https://lists.buildroot.org/mailman/listinfo/buildroot -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------' _______________________________________________ buildroot mailing list buildroot@buildroot.org https://lists.buildroot.org/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Buildroot] [PATCH] package/openssh: allow sandboxing to be disabled as workaround for seccomp issues 2022-09-18 14:58 ` Yann E. MORIN @ 2022-09-18 15:45 ` Peter Korsgaard 0 siblings, 0 replies; 4+ messages in thread From: Peter Korsgaard @ 2022-09-18 15:45 UTC (permalink / raw) To: Yann E. MORIN; +Cc: buildroot >>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes: > Peter, All, > On 2022-09-18 15:30 +0200, Peter Korsgaard spake thusly: >> As explained in bug #14796, there are situations where the seccomp based >> sandboxing in openssh can get confused, leading to connection issues. > [--SNIP--] >> As a workaround, add a _OPENSSH_SANDBOX option (defaulting to y) to decide >> if sandboxing should be used or not. > [--SNIP--] >> diff --git a/package/openssh/openssh.mk b/package/openssh/openssh.mk >> index 63a28f3af5..9fab2c9038 100644 >> --- a/package/openssh/openssh.mk >> +++ b/package/openssh/openssh.mk >> @@ -24,6 +24,7 @@ OPENSSH_CPE_ID_VENDOR = openbsd >> OPENSSH_CONF_OPTS = \ >> --sysconfdir=/etc/ssh \ >> --with-default-path=$(BR2_SYSTEM_DEFAULT_PATH) \ >> + $(if $(BR2_PACKAGE_OPENSSH_SANDBOX),--with-sandbox,--without-sandbox) \ > --with-sandbox expects an argument that specifies what type of sandbox > to use: > --with-sandbox=style Specify privilege separation sandbox (no, > capsicum, darwin, rlimit, seccomp_filter, > systrace, pledge) > If we just pass --with-sandbox without a value, configure will try to > look for a list of available sabdboxing mechanisms, and use the first it > finds: > https://github.com/openssh/openssh-portable/blob/1875042c52a3b950ae5963c9ca3774a4cc7f0380/configure.ac#L3642 Yes, exactly, --with-sandbox is use-the-best-available-sandbox option (E.G. the default, so if --with-sandbox / --without-sandbox is not used). > All that is before looks like it is BSD-only: pledge and systrace, or > darwin. But then, after seccomp, there is also capsicum and rlimit. > Capsicum on linux does not exist, and rlimit is probably does not bring > much security-wise... > So, in all practical matters, on Linux, sandboxing uses seccomp > filtering, or there is no sandboxing. > I've added a blurb to explain the above, and applied to master, thanks. Great, thanks. > Note that it looks like we can disable seccomp with: > ac_cv_have_decl_SECCOMP_MODE_FILTER=no That is also an option, but given that this no-sandbox thing is really special in the first case (and arguably because of a bug in glibc and/or how seccomp works), I think just having a way to disable it is good enough (tm). -- Bye, Peter Korsgaard _______________________________________________ buildroot mailing list buildroot@buildroot.org https://lists.buildroot.org/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Buildroot] [PATCH] package/openssh: allow sandboxing to be disabled as workaround for seccomp issues 2022-09-18 13:30 [Buildroot] [PATCH] package/openssh: allow sandboxing to be disabled as workaround for seccomp issues Peter Korsgaard 2022-09-18 14:58 ` Yann E. MORIN @ 2022-09-29 14:05 ` Peter Korsgaard 1 sibling, 0 replies; 4+ messages in thread From: Peter Korsgaard @ 2022-09-29 14:05 UTC (permalink / raw) To: buildroot >>>>> "Peter" == Peter Korsgaard <peter@korsgaard.com> writes: > As explained in bug #14796, there are situations where the seccomp based > sandboxing in openssh can get confused, leading to connection issues. > As explained by Thomas in the bug report: > glibc does not care about the kernel headers when deciding whether to try > the clock_gettime64() syscall or not: it always use it, and if that fails at > runtime, it falls back to clock_gettime(). This is how glibc ends up using > clock_gettime64() even if your kernel does not support it. > On the other hand, the OpenSSL seccomp code relies on kernel headers to decide > whether the clock_gettime64() syscall should be in the allowed list of syscalls > or not. > So when you are in a situation where glibc is recent, but your kernel is > older, you get into precisely the problem you have: glibc tries to use > clock_gettime64, but OpenSSH seccomp configuration prevents that, which does > not allow glibc to gracefully fallback to clock_gettime (as seccomp is > configured to kill the process on filter violations). > As a workaround, add a _OPENSSH_SANDBOX option (defaulting to y) to decide > if sandboxing should be used or not. > Fixes (works around) #14796 > Signed-off-by: Peter Korsgaard <peter@korsgaard.com> Committed to 2022.02.x, 2022.05.x and 2022.08.x, thanks. -- Bye, Peter Korsgaard _______________________________________________ buildroot mailing list buildroot@buildroot.org https://lists.buildroot.org/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-09-29 14:05 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2022-09-18 13:30 [Buildroot] [PATCH] package/openssh: allow sandboxing to be disabled as workaround for seccomp issues Peter Korsgaard 2022-09-18 14:58 ` Yann E. MORIN 2022-09-18 15:45 ` Peter Korsgaard 2022-09-29 14:05 ` Peter Korsgaard
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox