Bug#802211: Please, just patch rescue.service and emergency.service

Stijn van Drongelen rhymoid at gmail.com
Wed Oct 11 17:22:51 BST 2017

Hi everyone,

I obviously posted my ranty +1 to the wrong bugreport (#806852) and
didn't read this one thoroughly enough. My apologies for the noise.

In short: Marga Manterola is completely right about Michael Biebl's
example being convoluted. I might be wrong here, but I get
the impression that Biebl believes that a *properly* password-protected
GRUB would still allow an unauthenticated user to select the rescue mode
option. However, that would not be a proper configuration, because one
can configure GRUB in such a way that it restricts access to certain
menu entries. The part of the GRUB manual that explains how
password-protection can be enabled also gives examples of this.

If an attacker is not able to avoid GRUB, and GRUB is properly
secured (i.e. GRUB has the superusers environment variable set,
all accounts defined in grub.cfg use password_pbkdf2, grub.cfg and
its source files are not readable by unauthorised users, /boot is
encrypted, and every menu entry except the default one is restricted),
then only someone who can authenticate themselves as an administrator
can successfully order start any kind of rescue mode. At that point,
an extra password prompt will be mildly annoying at best. At worst,
the administrator realises that they forgot that password, because
it's never used, because in the year 2017, nobody who seriously cares
about security should ever log in as root during normal operation.
That's why rootless installations are so easy to create with d-i.

To be very blunt: I do not think that Biebl's example gives a valid
reason for concern. Someone who would be "overly paranoid" would already
have implemented the aforementioned security measures for GRUB, as well
as encrypting all other storage media. If an attacker has managed to get
through **all that** when a laptop that is "unattended for a moment",
a sulogin password prompt in rescue mode is very unlikely to be
an effective barrier. The only plausible attacker I can imagine here
is one that found non-technical means of recovering the GRUB password,
and if you're careless enough to let that one leak, the attacker will
also probably have your root password.

That said, I've implemented Manterola's snippets and I can confirm that
rescue mode works again. But please, admit that there's no good reason
to leave this 'important' bug open for over 720 days and just fix it:

Use sulogin --force for rescue.service and for emergency.service.

Stijn van Drongelen

More information about the Pkg-systemd-maintainers mailing list