Bug#926823: executable-not-elf-or-script should consider PE binaries
Control: reopen -1 ! Control: retitle -1 Make PE32+ binaries non-executable and enable security features Hi Michael, On Mon, Aug 5, 2019 at 3:23 PM Michael Biebl wrote: > > Why is this a bug in systemd then? A wishlist severity seemed appropriate to resolve this issue, hopefully once and for all. I was unable to boot with systemd-boot locally (and am not sure systemd-boot should use the EFI removable media path). Instead, I experimented with the EFI files from grub in my setup. Lintian currently issues two tags against the EFI files shipped with systemd. The tags named 'executable-not-elf-or-script' triggered your original bug filing. Then there are the tags named 'portable-executable-missing-security-features'. I will address both. With respect to 'executable-not-elf-or-script', I am unable to unset the executable permission on any file in my EFI partition (not even on icons shipped with rEFInd). That seems to be a feature of the FAT32 filesystem---which is specified for that partition---when mounted under Linux. All files are executable. [1] I think you can safely unset the executable bit on the EFI files shipped with systemd. The boot loader cannot tell the difference. As an aside, I will probably mount my EFI partition with 'noexec' in the future. Perhaps it should even be the default in Debian. With respect to the tags named 'portable-executable-missing-security-features', I am not sure what the features mean for an EFI boot, but they are easily changed. My system booted without a hitch after changing grubx64.efi (and, again, not systemd-boot's equivalent). I used 'genpeimg' from 'mingw-w64-tools'. (There is also 'pev'.) $ genpeimg -d +d -d +n -d +s $file Then, to verify that it worked: $ genpeimg -x $file ... Optional Characteristics: dynamic-base nx-compatible no-SEH While the security settings may not mean much to systemd-boot, it seemed a better avenue to adjust them than to override or ignore the related tags. > If ld creates those files with the executable bit set, it feels weird > that we have to work around that by manually removing that bit again. Should unauthorized executables manage to run, some of that responsibility will be shifted elsewhere: to the systemd-boot process in case of EFI loading, or to the standard mount options for FAT32 in case of unwanted execution under Linux. Kind regards, Felix [1] https://unix.stackexchange.com/questions/308056/why-does-unix-set-the-executable-flag-for-fat-file-systems
Bug#926823: executable-not-elf-or-script should consider PE binaries
Hi Michael, On Tue, Aug 6, 2019 at 1:12 AM Michael Biebl wrote: > > It just felt weird that all packages with PE executable either ignored > the lintian error or added an override. Thank you for this remark. I noticed that grub2 overrides similar tags. We will look into it. > Since I can't really be bothered to add an override, I'll just close > this bug report then. Please feel free to use the attached patch, which I created and tested for you (although it may not cover all architectures). Lintian may offer to add overrides interactively in the future. Kind regards Felix Lechner From 3ab0ec5551396e0e51577eb162564e2f35c1d95c Mon Sep 17 00:00:00 2001 From: Felix Lechner Date: Wed, 7 Aug 2019 04:35:57 -0700 Subject: [PATCH] Override Lintian error about missing security features in PE32+ binaries. These files may or may not need to be marked as executable, but many packages that ship similar files override or ignore the Lintian error. For example, grub2 ship override files with the following remark: "These aren't Windows executables, and these features wouldn't be very useful." --- debian/systemd.lintian-overrides | 2 ++ 1 file changed, 2 insertions(+) diff --git a/debian/systemd.lintian-overrides b/debian/systemd.lintian-overrides index f47d5b78d6..a8dfc4a106 100644 --- a/debian/systemd.lintian-overrides +++ b/debian/systemd.lintian-overrides @@ -1,2 +1,4 @@ systemd: maintainer-script-calls-systemctl +systemd: portable-executable-missing-security-features usr/lib/systemd/boot/efi/linuxx64.efi.stub ASLR DEP/NX +systemd: portable-executable-missing-security-features usr/lib/systemd/boot/efi/systemd-bootx64.efi ASLR DEP/NX systemd: possibly-insecure-handling-of-tmp-files-in-maintainer-script -- 2.20.1
Bug#926823: executable-not-elf-or-script should consider PE binaries
Hi Michael, On Mon, Aug 5, 2019 at 3:23 PM Michael Biebl wrote: > > Why is this a bug in systemd then? Dunno. I did not file the bug. I just know it's not in Lintian. :) > If ld creates those files with the executable bit set, it feels weird > that we have to work around that by manually removing that bit again. Is the bit required? With a view toward security, it seems disadvantageous to grant execution privileges to files not intended to run in Debian. I checked both the UEFI [1] and the systemd boot [2] specs, but found nothing about the executable bit. I planned to unset the bit locally until I realized my GRUB2 boot sequence may not use those files. Kind regards, Felix [1] https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf [2] https://systemd.io/BOOT_LOADER_SPECIFICATION
Bug#926823: executable-not-elf-or-script should consider PE binaries
On Mon, 5 Aug 2019 05:32:51 -0700 Felix Lechner wrote: > Hi, > > On Thu, May 2, 2019 at 9:27 AM Chris Lamb wrote: > > > > This begs the question; why cannot the systemd packaging remove the > > executable bits from these files? > > On my testing system post-buster, the executable bits are still set: > > $ ls -ald /usr/lib/systemd/boot/efi/* > -rwxr-xr-x 1 root root 59730 Jul 18 10:38 > /usr/lib/systemd/boot/efi/linuxx64.efi.stub > -rwxr-xr-x 1 root root 91765 Jul 18 10:38 > /usr/lib/systemd/boot/efi/systemd-bootx64.efi > > May I please assign this bug to package systemd? > Why is this a bug in systemd then? If ld creates those files with the executable bit set, it feels weird that we have to work around that by manually removing that bit again. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#926823: executable-not-elf-or-script should consider PE binaries
Control: reassign -1 systemd Control: severity -1 wishlist Hi, On Mon, Aug 5, 2019 at 5:48 AM Chris Lamb wrote: > > Can you clarify whom you are directing this query to? (I am unable to > answer it.) It was a matter of politeness, I suppose. Kind regards, Felix
Bug#926823: executable-not-elf-or-script should consider PE binaries
Felix Lechner wrote: > > This begs the question; why cannot the systemd packaging remove the > > executable bits from these files? > > On my testing system post-buster, the executable bits are still set: […] > May I please assign this bug to package systemd? Can you clarify whom you are directing this query to? (I am unable to answer it.) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org 🍥 chris-lamb.co.uk `-
Bug#926823: executable-not-elf-or-script should consider PE binaries
Hi, On Thu, May 2, 2019 at 9:27 AM Chris Lamb wrote: > > This begs the question; why cannot the systemd packaging remove the > executable bits from these files? On my testing system post-buster, the executable bits are still set: $ ls -ald /usr/lib/systemd/boot/efi/* -rwxr-xr-x 1 root root 59730 Jul 18 10:38 /usr/lib/systemd/boot/efi/linuxx64.efi.stub -rwxr-xr-x 1 root root 91765 Jul 18 10:38 /usr/lib/systemd/boot/efi/systemd-bootx64.efi May I please assign this bug to package systemd? Kind regards, Felix Lechner
Bug#926823: executable-not-elf-or-script should consider PE binaries
tags 926823 + moreinfo thanks Hi Michael, > Am 11.04.19 um 01:22 schrieb Felix Lechner: > > It's just that the lintian tag is not triggered when > > the [executable] bit is off. > > That much I figured :-) This begs the question; why cannot the systemd packaging remove the executable bits from these files? Indeed, they can't be "executed" in the usual way after all — the long description of the tag even refers to this although admittedly it mentions "Windows", not PE: Tag: executable-not-elf-or-script Severity: normal Certainty: certain Info: This executable file is not an ELF format binary, and does not start with the #! sequence that marks interpreted scripts. It might be a sh script that fails to name /bin/sh as its shell, or it may be incorrectly marked as executable. Sometimes upstream files developed on Windows are marked unnecessarily as executable on other systems. . If you are using debhelper to build your package, running dh_fixperms will often correct this problem for you. Ref: policy 10.4 Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org 🍥 chris-lamb.co.uk `-
Bug#926823: executable-not-elf-or-script should consider PE binaries
Am 11.04.19 um 01:22 schrieb Felix Lechner: > It's just that the lintian tag is not > triggered when the bit is off. That much I figured :-) -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#926823: executable-not-elf-or-script should consider PE binaries
On Wed, Apr 10, 2019 at 4:16 PM Michael Biebl wrote: > > Those bits are set by ld respectively objcopy when the binaries are > generated. Are you implying that ld/objcopy should not do that? No, you may well need it. It's just that the lintian tag is not triggered when the bit is off.
Bug#926823: executable-not-elf-or-script should consider PE binaries
Am 10.04.19 um 23:46 schrieb Felix Lechner: > On Wed, Apr 10, 2019 at 2:33 PM Michael Biebl wrote: >> >> systemd ships EFI binaries which are PE executables. >> >> usr/lib/systemd/boot/efi/linuxia32.efi.stub [amd64, i386] >> usr/lib/systemd/boot/efi/linuxx64.efi.stub [amd64, i386] >> usr/lib/systemd/boot/efi/systemd-bootia32.efi [amd64, i386] >> usr/lib/systemd/boot/efi/systemd-bootx64.efi [amd64, i386] >> >> I wonder whether executable-not-elf-or-script should be made aware of PE >> executables and not warn about them. > > Does systemd-boot require the executable bits to be set on these files? Those bits are set by ld respectively objcopy when the binaries are generated. Are you implying that ld/objcopy should not do that? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#926823: executable-not-elf-or-script should consider PE binaries
On Wed, Apr 10, 2019 at 2:33 PM Michael Biebl wrote: > > systemd ships EFI binaries which are PE executables. > > usr/lib/systemd/boot/efi/linuxia32.efi.stub [amd64, i386] > usr/lib/systemd/boot/efi/linuxx64.efi.stub [amd64, i386] > usr/lib/systemd/boot/efi/systemd-bootia32.efi [amd64, i386] > usr/lib/systemd/boot/efi/systemd-bootx64.efi [amd64, i386] > > I wonder whether executable-not-elf-or-script should be made aware of PE > executables and not warn about them. Does systemd-boot require the executable bits to be set on these files?
Bug#926823: executable-not-elf-or-script should consider PE binaries
Package: lintian Version: 2.12.0 Severity: normal Hi, systemd ships EFI binaries which are PE executables. This triggers lintian: executable-not-elf-or-script usr/lib/systemd/boot/efi/linuxia32.efi.stub [amd64, i386] usr/lib/systemd/boot/efi/linuxx64.efi.stub [amd64, i386] usr/lib/systemd/boot/efi/systemd-bootia32.efi [amd64, i386] usr/lib/systemd/boot/efi/systemd-bootx64.efi [amd64, i386] Some packages seem to override that, like in https://salsa.debian.org/efi-team/fwupd/blob/debian/debian/lintian/fwupd#L8 I wonder whether executable-not-elf-or-script should be made aware of PE executables and not warn about them. Regards, Michael -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils 2.31.1-16 ii bzip2 1.0.6-9 ii diffstat 1.62-1 ii dpkg 1.19.6 ii dpkg-dev 1.19.6 ii file 1:5.35-4 ii gettext0.19.8.1-9 ii gpg2.2.13-1 ii intltool-debian0.35.0+20060710.5 ii libapt-pkg-perl0.1.34+b1 ii libarchive-zip-perl1.64-1 ii libcapture-tiny-perl 0.48-1 ii libcgi-pm-perl 4.40-1 ii libclass-accessor-perl 0.51-1 ii libclone-perl 0.41-1+b1 ii libdigest-sha-perl 6.02-1+b1 ii libdpkg-perl 1.19.6 ii libemail-valid-perl1.202-1 ii libfile-basedir-perl 0.08-1 ii libio-async-perl 0.72-1 ii libipc-run-perl20180523.0-1 ii liblist-moreutils-perl 0.416-1+b4 ii libparse-debianchangelog-perl 1.2.0-13 ii libpath-tiny-perl 0.108-1 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3000-2 ii libtry-tiny-perl 0.30-1 ii liburi-perl1.76-1 ii libxml-simple-perl 2.25-1 ii libyaml-libyaml-perl 0.76+repack-1 ii man-db 2.8.5-2 ii patchutils 0.3.4-2 ii perl 5.28.1-6 ii t1utils1.41-3 ii xz-utils 5.2.4-1 Versions of packages lintian recommends: ii libperlio-gzip-perl 0.19-1+b5 Versions of packages lintian suggests: pn binutils-multiarch ii libhtml-parser-perl3.72-3+b3 ii libtext-template-perl 1.55-1 -- no debconf information
