Bug#959070: klibc-utils: fstype falsely claims to need an executable stack
On Wed, 2020-04-29 at 20:41 +0200, Helge Deller wrote: > On 29.04.20 15:36, Ben Hutchings wrote: > > Control: tag -1 upstream fixed-upstream patch > > > > On Wed, 2020-04-29 at 14:12 +1000, Russell Coker wrote: > > > Package: klibc-utils > > > Version: 2.0.7-1 > > > Severity: normal > > > > > > root@sevm:~/pol# /usr/lib/klibc/bin/fstype < /dev/sda2 > > > Segmentation fault > > > root@sevm:~/pol# execstack -c /usr/lib/klibc/bin/fstype > > > root@sevm:~/pol# /usr/lib/klibc/bin/fstype < /dev/sda2 > > > FSTYPE=btrfs > > > FSSIZE=719360278528 > > > > > > The fstype program is listed as needing an executable stack, which will > > > cause > > > it to crash when run on a system with a security policy preventing > > > executable > > > stacke. If you clear the execstack bit it appears to work correctly. > > [...] > > > > I've fixed this upstream but not made a new release yet: > > > > https://git.kernel.org/pub/scm/libs/klibc/klibc.git/commit/?id=9d8d648e604026b32cad00a84ed6c29cbd157641 > > On hppa/parisc we still need executable stacks for the signal trampoline > return code. > Might your patch then maybe break fstype on hppa? > I didn't tested it... Kees Cook mentioned that too: https://lists.zytor.com/archives/klibc/2020-February/004273.html but I couldn't find any sign of it in the current code. Looking again, I see that I was confused: the *kernel* creates these trampolines on the stack. On some architecturers (m68k and parisc) this is done unconditionally; on others (alpha, s390, and sparc 32-bit) it's done if sa_restorer is not set (and we don't set it for them). Presumably m68k and parisc are actually fine at the moment, as gcc won't disable execstack on its output. However alpha, s390, and sparc will be broken if gcc is configured assuming the C library will set sa_restorer and it disables execstack. I shall make the execstack flag setting arch-dependent. Ben. -- Ben Hutchings Horngren's Observation: Among economists, the real world is often a special case. signature.asc Description: This is a digitally signed message part
Bug#959070: klibc-utils: fstype falsely claims to need an executable stack
Helge Deller dixit: >On hppa/parisc we still need executable stacks for the signal >trampoline return code. Might your patch then maybe break fstype on >hppa? I didn't tested it... I think it only changed the assembly parts of the library to signal to the linker that there’s no need for an executable stack on their account, but the signal handling code should¹ add one on hppa then. ① also not tested, maybe you should ☻ bye, //mirabilos -- When he found out that the m68k port was in a pretty bad shape, he did not, like many before him, shrug and move on; instead, he took it upon himself to start compiling things, just so he could compile his shell. How's that for dedication. -- Wouter, about my Debian/m68k revival
Bug#959070: klibc-utils: fstype falsely claims to need an executable stack
On 29.04.20 15:36, Ben Hutchings wrote: > Control: tag -1 upstream fixed-upstream patch > > On Wed, 2020-04-29 at 14:12 +1000, Russell Coker wrote: >> Package: klibc-utils >> Version: 2.0.7-1 >> Severity: normal >> >> root@sevm:~/pol# /usr/lib/klibc/bin/fstype < /dev/sda2 >> Segmentation fault >> root@sevm:~/pol# execstack -c /usr/lib/klibc/bin/fstype >> root@sevm:~/pol# /usr/lib/klibc/bin/fstype < /dev/sda2 >> FSTYPE=btrfs >> FSSIZE=719360278528 >> >> The fstype program is listed as needing an executable stack, which will cause >> it to crash when run on a system with a security policy preventing executable >> stacke. If you clear the execstack bit it appears to work correctly. > [...] > > I've fixed this upstream but not made a new release yet: > > https://git.kernel.org/pub/scm/libs/klibc/klibc.git/commit/?id=9d8d648e604026b32cad00a84ed6c29cbd157641 On hppa/parisc we still need executable stacks for the signal trampoline return code. Might your patch then maybe break fstype on hppa? I didn't tested it... Helge signature.asc Description: OpenPGP digital signature
Processed: Re: Bug#959070: klibc-utils: fstype falsely claims to need an executable stack
Processing control commands: > tag -1 upstream fixed-upstream patch Bug #959070 [klibc-utils] klibc-utils: fstype falsely claims to need an executable stack Added tag(s) patch, upstream, and fixed-upstream. -- 959070: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959070 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#959070: klibc-utils: fstype falsely claims to need an executable stack
Control: tag -1 upstream fixed-upstream patch On Wed, 2020-04-29 at 14:12 +1000, Russell Coker wrote: > Package: klibc-utils > Version: 2.0.7-1 > Severity: normal > > root@sevm:~/pol# /usr/lib/klibc/bin/fstype < /dev/sda2 > Segmentation fault > root@sevm:~/pol# execstack -c /usr/lib/klibc/bin/fstype > root@sevm:~/pol# /usr/lib/klibc/bin/fstype < /dev/sda2 > FSTYPE=btrfs > FSSIZE=719360278528 > > The fstype program is listed as needing an executable stack, which will cause > it to crash when run on a system with a security policy preventing executable > stacke. If you clear the execstack bit it appears to work correctly. [...] I've fixed this upstream but not made a new release yet: https://git.kernel.org/pub/scm/libs/klibc/klibc.git/commit/?id=9d8d648e604026b32cad00a84ed6c29cbd157641 Ben. -- Ben Hutchings Horngren's Observation: Among economists, the real world is often a special case. signature.asc Description: This is a digitally signed message part
Bug#959070: klibc-utils: fstype falsely claims to need an executable stack
Package: klibc-utils Version: 2.0.7-1 Severity: normal root@sevm:~/pol# /usr/lib/klibc/bin/fstype < /dev/sda2 Segmentation fault root@sevm:~/pol# execstack -c /usr/lib/klibc/bin/fstype root@sevm:~/pol# /usr/lib/klibc/bin/fstype < /dev/sda2 FSTYPE=btrfs FSSIZE=719360278528 The fstype program is listed as needing an executable stack, which will cause it to crash when run on a system with a security policy preventing executable stacke. If you clear the execstack bit it appears to work correctly. https://akkadia.org/drepper/nonselsec.pdf Page 8 of Ulrich Drepper's document about non-SE Linux security explains the options for dealing with this. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.5.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Enforcing - Policy name: default Versions of packages klibc-utils depends on: ii libklibc 2.0.7-1 klibc-utils recommends no packages. klibc-utils suggests no packages. -- no debconf information -- debsums errors found: debsums: changed file /usr/lib/klibc/bin/fstype (from klibc-utils package)
