Bug 737604 – net-misc/openssh: sys-devel/glibc-2.31-r6 breaks logins on i386 due to syscall blocked by sandbox-seccomp-filter

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Huemi 2020-08-17 08:56:34 UTC]

You have to add
	/* Syscalls to permit */
	SC_ALLOW(407),

in sandbox-seccomp-filter.c to make ssh login working again


Reproducible: Always

Steps to Reproduce:
Upgrade to glibc-2.31-r6
Reboot
Try to login via ssh
Actual Results:  
Before you can enter the password the connection is closed. Recompiling openssh with 
#define SANDBOX_SECCOMP_FILTER_DEBUG 1
and removing the block

#ifdef SANDBOX_SECCOMP_FILTER_DEBUG
/* Use the kernel headers in case of an older toolchain. */
# include <asm/siginfo.h>
# define __have_siginfo_t 1
# define __have_sigval_t 1
# define __have_sigevent_t 1
#endif /* SANDBOX_SECCOMP_FILTER_DEBUG */

reveals:
debug3: ensure_minimum_time_since: elapsed [deleted]ms, delaying [deleted]ms (requested [deleted]ms) [preauth]
ssh_sandbox_violation: unexpected system call (arch:0x40000003,syscall:407 @ 0xb7ed8a82) [preauth]



Expected Results:  
Somebody would have to convert 407 to a _NR_... statement to find out what really happens, but adding SC_ALLOW(407) works to make ssh login working again. 

This should be added to the i386 glibc-2.31 patches for openssh as it is quite annyoing being locked out from your remote computer.

I don't know whether this is:
"* System call wrappers for time system calls now use the new time64
  system calls when available. On 32-bit targets, these wrappers
  attempt to call the new system calls first and fall back to the
  older 32-bit time system calls if they are not present.  This may
  cause issues in environments that cannot handle unsupported system
  calls gracefully by returning -ENOSYS. Seccomp sandboxes are
  affected by this issue."

or if it is another incompatible glibc-2.31 change.

[Comment 1 Huemi 2020-08-17 09:00:11 UTC]

Recompiling openssh after merging glibc-2.31-r6 (and rebooting) without this manual modification and restarting it didn't help on x86 architecture, so this workaround you find somewhere might only work on amd64, but x86 seems to be using another system call which is missing in the current patchset.

[Comment 2 Alexander Tsoy 2020-08-17 10:37:55 UTC]

(In reply to Huemi from comment #0)
> Somebody would have to convert 407 to a _NR_... statement to find out what
> really happens, but adding SC_ALLOW(407) works to make ssh login working
> again. 
/usr/include/asm/unistd_32.h:#define __NR_clock_nanosleep_time64 407

And AFAIS, it is enabled by openssh patchset.

What version of linux-headers is installed on your systemd? (Or better post emerge --info output)

[Comment 3 Huemi 2020-08-17 11:13:46 UTC]

Linux headers 4.19 (installed at the beginning of 2020) doesn't seem to include this call. As I use a 4.19.x series kernel I didn't want to upgrade to 5.4-r1 as it wouldn't match the kernel ...

cat /usr/include/asm/unistd_32.h | grep __NR_clock_nanosleep
#define __NR_clock_nanosleep 267

---
As the openssh patchset only includes:
#ifdef __NR_clock_nanosleep
	SC_ALLOW(__NR_clock_nanosleep),
#endif
#ifdef __NR_clock_nanosleep_time64
	SC_ALLOW(__NR_clock_nanosleep_time64),
#endif

The SC_ALLOW will probably be never compiled because __NR_clock_nanosleep_time64 is not defined. 

So maybe it should be allowed unconditionally to workaround - but if it isn't defined you would have to add 407 statically ...

---
sys-kernel/linux-headers: 4.19::gentoo (virtual/os-headers)
sys-libs/glibc:           2.31-r6::gentoo
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=i686 -pipe"
CHOST="i686-pc-linux-gnu"
CXXFLAGS="-O2 -march=i686 -pipe"

[Comment 4 Huemi 2020-08-17 11:14:46 UTC]

Should not be "doesn't contain this call" but "doesn't contain this define statement".

[Comment 5 Alexander Tsoy 2020-08-17 11:21:47 UTC]

(In reply to Huemi from comment #3)
> Linux headers 4.19 (installed at the beginning of 2020) doesn't seem to
> include this call. As I use a 4.19.x series kernel I didn't want to upgrade
> to 5.4-r1 as it wouldn't match the kernel ...
As was discussed multiple times at multiple places (including this BZ), having newer linux-headers is a perfectly supported configuration.

(In reply to Huemi from comment #3)
> So maybe it should be allowed unconditionally to workaround - but if it
> isn't defined you would have to add 407 statically ...
Yeah, I think gentoo should apply patch for openssh that hardcodes these syscall numbers... until old versions of linux-headers are dropped. The only problem is that some arches may have different syscall numbers, but I'm not sure if this is possible.

[Comment 6 Alexander Tsoy 2020-08-17 12:20:31 UTC]

(In reply to Alexander Tsoy from comment #5)
> The only problem is that some arches may have different syscall numbers,
> but I'm not sure if this is possible.
I just checked syscalls added by openssh patchset. It seems like "clock_gettime64" and "clock_nanosleep_time64" have identical numbers on different arches (403 and 407). But since these syscalls only available on 32-bit arches, the patch would be slightly complicated (a lot of "if defined"/"elif defined").
"ipc" and "clock_nanosleep" syscalls have different numbers on different arches, but these syscalls are probably defined by the linux headers for a very long time, so no need to add them.

[Comment 7 Larry the Git Cow 2020-08-17 14:32:39 UTC]

The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a3ddee3a0c95e932481d494930a05f6f34938c1e

commit a3ddee3a0c95e932481d494930a05f6f34938c1e
Author:     Thomas Deutschmann <[e-mail]>
AuthorDate: 2020-08-17 14:29:28 +0000
Commit:     Thomas Deutschmann <[e-mail]>
CommitDate: 2020-08-17 14:32:33 +0000

    net-misc/openssh: depend on >=sys-kernel/linux-headers-5.1
    
    In >=sys-libs/glibc-2.31 we are already forcing an upgrade of net-misc/openssh.
    However, sandbox code in OpenSSH [Link 1] is guarded by "#ifdef" so an upgrade
    of OpenSSH before glibc upgrade won't fix the problem if system is using old
    linux-headers without __NR_clock_nanosleep{,_time64}.
    
    Forcing >=linux-headers-5.1 will ensure that OpenSSH's sandbox supports
    __NR_clock_nanosleep{,_time64} and will therefore work with >=glibc-2.31.
    
    Link 1: https://github.com/openssh/openssh-portable/blob/V_8_3/sandbox-seccomp-filter.c#L252-L257
    Bug: https://bugs.gentoo.org/708224
    Closes: https://bugs.gentoo.org/737604
    Package-Manager: Portage-3.0.2, Repoman-2.3.23
    Signed-off-by: Thomas Deutschmann <[e-mail]>

 .../openssh/{openssh-8.1_p1-r3.ebuild => openssh-8.1_p1-r4.ebuild}     | 3 ++-
 .../openssh/{openssh-8.2_p1-r6.ebuild => openssh-8.2_p1-r7.ebuild}     | 3 ++-
 .../openssh/{openssh-8.3_p1-r4.ebuild => openssh-8.3_p1-r5.ebuild}     | 3 ++-
 3 files changed, 6 insertions(+), 3 deletions(-)