All of lore.kernel.org
 help / color / mirror / Atom feed
* [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.