Bug#849923: openssh-server: no login possible after upgrade on x32
On Tue, Jan 03, 2017 at 05:23:21PM +0100, Sven Joachim wrote: > On 2017-01-03 15:30 +, Colin Watson wrote: > > On Tue, Jan 03, 2017 at 03:51:03PM +0100, Thorsten Glaser wrote: > >> Helmut Grohne suggests to always pass both, even if equal. Probably > >> to eliminate an entire error class, even if not necessary. *shrug* > >> If this works, all the better. > > > > /usr/share/doc/autotools-dev/README.Debian.gz claims that it causes > > modern autoconf to switch to cross-compiling mode even if the values are > > equal (though I haven't tracked down the exact details of this). > > That's not quite correct, but many people have been wondering about it. > You can see my own ramblings in #682780[1], on the upstream mailing I > received a reply stating that cross-compiling mode is not to be entered > in this case[2]. Thanks for the clarification! I'm still happy to leave this up to debhelper rather than specifically overriding it in individual packages, I think. -- Colin Watson [cjwat...@debian.org]
Bug#849923: openssh-server: no login possible after upgrade on x32
On 2017-01-03 15:30 +, Colin Watson wrote: > On Tue, Jan 03, 2017 at 03:51:03PM +0100, Thorsten Glaser wrote: >> On Tue, 3 Jan 2017, Colin Watson wrote: >> >> Helmut Grohne suggests to always pass both, even if equal. Probably >> to eliminate an entire error class, even if not necessary. *shrug* >> If this works, all the better. > > /usr/share/doc/autotools-dev/README.Debian.gz claims that it causes > modern autoconf to switch to cross-compiling mode even if the values are > equal (though I haven't tracked down the exact details of this). That's not quite correct, but many people have been wondering about it. You can see my own ramblings in #682780[1], on the upstream mailing I received a reply stating that cross-compiling mode is not to be entered in this case[2]. Cheers, Sven 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682780 2. https://lists.gnu.org/archive/html/autoconf/2012-07/msg00014.html
Bug#849923: openssh-server: no login possible after upgrade on x32
On Tue, Jan 03, 2017 at 03:51:03PM +0100, Thorsten Glaser wrote: > On Tue, 3 Jan 2017, Colin Watson wrote: > > Here's a better stopgap that lets us keep the sandbox enabled: > > > > > > https://anonscm.debian.org/cgit/pkg-ssh/openssh.git/commit/?id=e346421ca6852fbf9f95cf0e764ecc345e5ce21d > > Oooh, that looks promising… did you upload, or should I test beforehand? > I have about half an hour remaining here in which I can test… I tested locally and then uploaded (1:7.4p1-5). > > You're probably being misled by config.guess's default, but that's > > already overridden appropriately by dpkg/debhelper. > > Ouch, too much magic… I had d/rules spew out confflags, but apparently > some dh7 magic adds even more flags then. It's handled by /usr/share/perl5/Debian/Debhelper/Buildsystem/autoconf.pm. If you need to see what commands it runs, it's simplest to just set DH_VERBOSE=1. > > Unnecessary: the default is --build=x86_64-linux-gnux32, and --host > > shouldn't be passed when not cross-compiling. > > Helmut Grohne suggests to always pass both, even if equal. Probably > to eliminate an entire error class, even if not necessary. *shrug* > If this works, all the better. /usr/share/doc/autotools-dev/README.Debian.gz claims that it causes modern autoconf to switch to cross-compiling mode even if the values are equal (though I haven't tracked down the exact details of this). Helmut's advice was certainly valid with old autoconf ... -- Colin Watson [cjwat...@debian.org]
Bug#849923: openssh-server: no login possible after upgrade on x32
On Tue, 3 Jan 2017, Colin Watson wrote: > > Can you please forward this to someone at the kernel side (either Debian > > or upstream) who can have a look? In the meantime, I’ll point this issue > > out in #debian-x32 on IRC, so the other porters can also look. > > I've cloned a kernel bug for this with this message. Thanks! > Here's a better stopgap that lets us keep the sandbox enabled: > > > https://anonscm.debian.org/cgit/pkg-ssh/openssh.git/commit/?id=e346421ca6852fbf9f95cf0e764ecc345e5ce21d Oooh, that looks promising… did you upload, or should I test beforehand? I have about half an hour remaining here in which I can test… > You're probably being misled by config.guess's default, but that's > already overridden appropriately by dpkg/debhelper. Ouch, too much magic… I had d/rules spew out confflags, but apparently some dh7 magic adds even more flags then. I hand-patched configure to debug $host, so I had to invoke it manually, and I knew from other pak‐ kages that build/host had to be added. > Unnecessary: the default is --build=x86_64-linux-gnux32, and --host > shouldn't be passed when not cross-compiling. Helmut Grohne suggests to always pass both, even if equal. Probably to eliminate an entire error class, even if not necessary. *shrug* If this works, all the better. Thanks again, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Processed: Re: Bug#849923: openssh-server: no login possible after upgrade on x32
Processing commands for cont...@bugs.debian.org: > clone 849923 -1 Bug #849923 [openssh-server] openssh-server: (default) UsePrivilegeSeparation sandbox broken on x32 Bug 849923 cloned as bug 850047 > reassign -1 linux Bug #850047 [openssh-server] openssh-server: (default) UsePrivilegeSeparation sandbox broken on x32 Bug reassigned from package 'openssh-server' to 'linux'. No longer marked as found in versions openssh/1:7.4p1-3. Ignoring request to alter fixed versions of bug #850047 to the same values previously set > retitle -1 linux: x32 __vdso_clock_gettime falls back to x86-64 syscall Bug #850047 [linux] openssh-server: (default) UsePrivilegeSeparation sandbox broken on x32 Changed Bug title to 'linux: x32 __vdso_clock_gettime falls back to x86-64 syscall' from 'openssh-server: (default) UsePrivilegeSeparation sandbox broken on x32'. > thanks Stopping processing here. Please contact me if you need assistance. -- 849923: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849923 850047: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850047 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#849923: openssh-server: no login possible after upgrade on x32
clone 849923 -1
reassign -1 linux
retitle -1 linux: x32 __vdso_clock_gettime falls back to x86-64 syscall
thanks
On Tue, Jan 03, 2017 at 02:31:35PM +0100, Thorsten Glaser wrote:
> On Mon, 2 Jan 2017, Aurelien Jarno wrote:
> > Looking at the issue, it actually appears in __vdso_clock_gettime, which
> > is provided by the kernel. This code handle the simple cases (REALTIME,
> > MONOTONIC, REALTIME_COARSE and _MONOTONIC_COARSE) and fallbacks to
> > the syscall in otherwise, CLOCK_BOOTTIME in the case of sshd.
>
> Ouch – and the kernel probably thinks it’s getting away with this as
> the kernel architecture is amd64…
>
> Can you please forward this to someone at the kernel side (either Debian
> or upstream) who can have a look? In the meantime, I’ll point this issue
> out in #debian-x32 on IRC, so the other porters can also look.
I've cloned a kernel bug for this with this message.
> > On 2017-01-02 17:49, Colin Watson wrote:
>
> > > sshd's seccomp sandbox is denying a clock_gettime call. But it's more
>
> Probably a stupid idea, but a short-term stopgap: can we disable seccomp
> on x32 for now? That needs:
Here's a better stopgap that lets us keep the sandbox enabled:
https://anonscm.debian.org/cgit/pkg-ssh/openssh.git/commit/?id=e346421ca6852fbf9f95cf0e764ecc345e5ce21d
> • in debian/rules:
> +confflags += --host=${DEB_HOST_GNU_TYPE}
> This sets $host to x86_64-pc-linux-gnux32 instead of the
> auto-detected x86_64-pc-linux-gnu (which is amd64)
Unnecessary: the default is --build=x86_64-linux-gnux32, and --host
shouldn't be passed when not cross-compiling.
You're probably being misled by config.guess's default, but that's
already overridden appropriately by dpkg/debhelper.
Cheers,
--
Colin Watson [cjwat...@debian.org]
Bug#849923: openssh-server: no login possible after upgrade on x32
On Mon, 2 Jan 2017, Aurelien Jarno wrote:
> Looking at the issue, it actually appears in __vdso_clock_gettime, which
> is provided by the kernel. This code handle the simple cases (REALTIME,
> MONOTONIC, REALTIME_COARSE and _MONOTONIC_COARSE) and fallbacks to
> the syscall in otherwise, CLOCK_BOOTTIME in the case of sshd.
Ouch – and the kernel probably thinks it’s getting away with this as
the kernel architecture is amd64…
Can you please forward this to someone at the kernel side (either Debian
or upstream) who can have a look? In the meantime, I’ll point this issue
out in #debian-x32 on IRC, so the other porters can also look.
> On 2017-01-02 17:49, Colin Watson wrote:
> > sshd's seccomp sandbox is denying a clock_gettime call. But it's more
Probably a stupid idea, but a short-term stopgap: can we disable seccomp
on x32 for now? That needs:
• in debian/rules:
+confflags += --host=${DEB_HOST_GNU_TYPE}
This sets $host to x86_64-pc-linux-gnux32 instead of the
auto-detected x86_64-pc-linux-gnu (which is amd64)
• in configure.ac:
AC_MSG_CHECKING([for seccomp architecture])
seccomp_audit_arch=
case "$host" in
+x86_64-*-gnux32)
+ # disabled for now, see Debian #849923
+ ;;
x86_64-*)
seccomp_audit_arch=AUDIT_ARCH_X86_64
;;
With this, we can then also later fix the architecture, should
the kernel be fixed.
Thanks,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Bug#849923: openssh-server: no login possible after upgrade on x32
On 2017-01-02 17:49, Colin Watson wrote: > On Mon, Jan 02, 2017 at 11:36:55AM +0100, Thorsten Glaser wrote: > > After upgrading from 1:7.3p1-5 to 1:7.4p1-3 I can no longer > > 'ssh localhost' on x32; switching to openssh-server:i386 with > > the exact same configuration works, though. > > sshd's seccomp sandbox is denying a clock_gettime call. But it's more > interesting than that: its seccomp filter allows clock_gettime; but the > actual syscall being used is not the x32 clock_gettime (with bit 30 > set), but the x86-64 variant instead. > > You can see a similar effect like this in an x32 environment: > > strace dmesg -e > > ... and buried in the output you'll find something like: > > strace: syscall_228(...) in unsupported 64-bit mode of process PID=19943 > > Neither sshd nor dmesg is using anything like manual syscall(2) here, > just the glibc wrappers. > > This feels like a glibc bug to me. Shouldn't it be using x32 syscalls > consistently? The x86-64 variants work, but that's not very > seccomp-friendly. (And if necessary I can hack around it in sshd, but > if you agree that it's a glibc bug then I think it should simply be > fixed there.) Looking at the issue, it actually appears in __vdso_clock_gettime, which is provided by the kernel. This code handle the simple cases (REALTIME, MONOTONIC, REALTIME_COARSE and _MONOTONIC_COARSE) and fallbacks to the syscall in otherwise, CLOCK_BOOTTIME in the case of sshd. This therefore looks like a kernel issue to me. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#849923: openssh-server: no login possible after upgrade on x32
On Mon, Jan 02, 2017 at 11:36:55AM +0100, Thorsten Glaser wrote: > After upgrading from 1:7.3p1-5 to 1:7.4p1-3 I can no longer > 'ssh localhost' on x32; switching to openssh-server:i386 with > the exact same configuration works, though. sshd's seccomp sandbox is denying a clock_gettime call. But it's more interesting than that: its seccomp filter allows clock_gettime; but the actual syscall being used is not the x32 clock_gettime (with bit 30 set), but the x86-64 variant instead. You can see a similar effect like this in an x32 environment: strace dmesg -e ... and buried in the output you'll find something like: strace: syscall_228(...) in unsupported 64-bit mode of process PID=19943 Neither sshd nor dmesg is using anything like manual syscall(2) here, just the glibc wrappers. This feels like a glibc bug to me. Shouldn't it be using x32 syscalls consistently? The x86-64 variants work, but that's not very seccomp-friendly. (And if necessary I can hack around it in sshd, but if you agree that it's a glibc bug then I think it should simply be fixed there.) Thanks, -- Colin Watson [cjwat...@debian.org]
Processed: Re: Bug#849923: openssh-server: no login possible after upgrade on x32
Processing commands for cont...@bugs.debian.org: > retitle 849923 openssh-server: (default) UsePrivilegeSeparation sandbox > broken on x32 Bug #849923 [openssh-server] openssh-server: no login possible after upgrade on x32 Changed Bug title to 'openssh-server: (default) UsePrivilegeSeparation sandbox broken on x32' from 'openssh-server: no login possible after upgrade on x32'. > thanks Stopping processing here. Please contact me if you need assistance. -- 849923: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849923 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#849923: openssh-server: no login possible after upgrade on x32
retitle 849923 openssh-server: (default) UsePrivilegeSeparation sandbox broken on x32 thanks On Mon, 2 Jan 2017, Thorsten Glaser wrote: > After upgrading from 1:7.3p1-5 to 1:7.4p1-3 I can no longer > 'ssh localhost' on x32; switching to openssh-server:i386 with > the exact same configuration works, though. I can get the x32 package working by adding… UsePrivilegeSeparation yes … instead of sandbox to /etc/ssh/sshd_config and restarting. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Bug#849923: openssh-server: no login possible after upgrade on x32
Package: openssh-server Version: 1:7.4p1-3 Severity: important After upgrading from 1:7.3p1-5 to 1:7.4p1-3 I can no longer 'ssh localhost' on x32; switching to openssh-server:i386 with the exact same configuration works, though. Server log: tglase@tglase:~ $ sudo cleanenv / /usr/sbin/sshd -de debug2: load_server_config: filename /etc/ssh/sshd_config debug2: load_server_config: done config len = 366 debug2: parse_server_config: config /etc/ssh/sshd_config len 366 debug3: /etc/ssh/sshd_config:18 setting HostKey /etc/ssh/ssh_host_rsa_key debug3: /etc/ssh/sshd_config:33 setting PermitRootLogin prohibit-password debug3: /etc/ssh/sshd_config:42 setting AuthorizedKeysFile .ssh/authorized_keys debug3: /etc/ssh/sshd_config:63 setting ChallengeResponseAuthentication no debug3: /etc/ssh/sshd_config:86 setting UsePAM yes debug3: /etc/ssh/sshd_config:91 setting X11Forwarding yes debug3: /etc/ssh/sshd_config:95 setting PrintMotd no debug3: /etc/ssh/sshd_config:115 setting AcceptEnv LANG LC_* debug3: /etc/ssh/sshd_config:118 setting Subsystem sftp /usr/lib/openssh/sftp-server debug1: sshd version OpenSSH_7.4, OpenSSL 1.0.2j 26 Sep 2016 debug1: private host key #0: ssh-rsa SHA256:9ae2/1t8U30Savg3XisO1ZCDuaH8IXQm18FdLpW3g8M debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-de' debug3: oom_adjust_setup debug1: Set /proc/self/oom_score_adj from 0 to -1000 debug2: fd 3 setting O_NONBLOCK debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. debug2: fd 4 setting O_NONBLOCK debug3: sock_set_v6only: set socket 4 IPV6_V6ONLY debug1: Bind to port 22 on ::. Server listening on :: port 22. debug3: fd 5 is not O_NONBLOCK debug1: Server will not fork when running in debugging mode. debug3: send_rexec_state: entering fd = 8 config len 366 debug3: ssh_msg_send: type 0 debug3: send_rexec_state: done debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8 debug3: recv_rexec_state: entering fd = 5 debug3: ssh_msg_recv entering debug3: recv_rexec_state: done debug2: parse_server_config: config rexec len 366 debug3: rexec:18 setting HostKey /etc/ssh/ssh_host_rsa_key debug3: rexec:33 setting PermitRootLogin prohibit-password debug3: rexec:42 setting AuthorizedKeysFile .ssh/authorized_keys debug3: rexec:63 setting ChallengeResponseAuthentication no debug3: rexec:86 setting UsePAM yes debug3: rexec:91 setting X11Forwarding yes debug3: rexec:95 setting PrintMotd no debug3: rexec:115 setting AcceptEnv LANG LC_* debug3: rexec:118 setting Subsystem sftp/usr/lib/openssh/sftp-server debug1: sshd version OpenSSH_7.4, OpenSSL 1.0.2j 26 Sep 2016 debug1: private host key #0: ssh-rsa SHA256:9ae2/1t8U30Savg3XisO1ZCDuaH8IXQm18FdLpW3g8M debug1: inetd sockets after dupping: 3, 3 Connection from 127.0.0.1 port 49750 on 127.0.0.1 port 22 debug1: Client protocol version 2.0; client software version OpenSSH_7.4p1 Debian-3 debug1: match: OpenSSH_7.4p1 Debian-3 pat OpenSSH* compat 0x0400 debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-3 debug1: Enabling compatibility mode for protocol 2.0 debug2: fd 3 setting O_NONBLOCK debug3: ssh_sandbox_init: preparing seccomp filter sandbox debug2: Network child is on pid 31321 debug3: preauth child monitor started debug3: privsep user:group 111:65534 [preauth] debug1: permanently_set_uid: 111/65534 [preauth] debug3: ssh_sandbox_child: setting PR_SET_NO_NEW_PRIVS [preauth] debug3: ssh_sandbox_child: attaching seccomp filter program [preauth] debug1: list_hostkey_types: ssh-rsa,rsa-sha2-512,rsa-sha2-256 [preauth] debug3: send packet: type 20 [preauth] debug1: SSH2_MSG_KEXINIT sent [preauth] debug3: receive packet: type 20 [preauth] debug1: SSH2_MSG_KEXINIT received [preauth] debug2: local server KEXINIT proposal [preauth] debug2: KEX algorithms: curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1 [preauth] debug2: host key algorithms: ssh-rsa,rsa-sha2-512,rsa-sha2-256 [preauth] debug2: ciphers ctos: chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com [preauth] debug2: ciphers stoc: chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com [preauth] debug2: MACs ctos: umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 [preauth] debug2: MACs stoc: umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 [preauth] debug2: compression ctos: none,z...@openssh.com [preauth] debug2: compression stoc: none,z...@openssh.com [preauth]
