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 <bi...@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
