Bug#926823: executable-not-elf-or-script should consider PE binaries

[Felix Lechner]

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 <biebl at debian.org> 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