* [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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.