Bug#802211: systemd: rescue.service fails if root password is not set

[Andreas Henriksson]

Hello Michael Biebl.

I'm going to add some historic background here which hopefully helps
you understand where we currently stand unless you already know
about this.

During stretch development cycle the 'sulogin' binary was taken
over by 'util-linux' package. It was previously shipped in
sysvinit-utils.
The sysvinit-utils version carried a Debian-specific patch:
http://sources.debian.net/src/sysvinit/2.88dsf-59/debian/patches/91_sulogin_lockedpw.dpatch/

This patch was *not* carried over when switching to util-linux
implementation. Martin Pitt submitted the patch for upstream
inclusion and I reviewed it finding that it had serious flaws.
https://github.com/karelzak/util-linux/pull/200
(Unfortunately github seems to have misplaced my initial
in-code review commends after force push of updated version.)

The entire patch was then rejected based on security consideration.
Upstream reasoned that a locked account should probably stay
locked in the regular case. If you wanted to override that behaviour
it was implemented under the --force option of sulogin.
It was first supported in util-linux (>= 2.27~rc1-1~),
even though the --force flag itself existed in earlier versions.

The practical example for why you do *not* want Debians behaviour
was mentioned as somthing along the lines of 'think of a kiosk which
people shakes around and eventually the filesystem might need fsck.
You don't want to hand out passwordless root shell to kiosk users.'


On Mon, Nov 09, 2015 at 02:12:10AM +0100, Michael Biebl wrote:
> Control: tags -1 + moreinfo
> 
> Am 18.10.2015 um 14:25 schrieb Mattia Monga:
[...]
> > When the root account is locked or its password is not set,
> > rescue.service fails to get a root shell. The solution is to call
> > sulogin with --force option.
> 
> I'm worried that this might open up a security hole.
> Do we know how sysvinit behaved in that case?

As explained above, we used to just hand out passwordless root shells
(no matter which init system was used).

Our current (buggy?) behaviour is you have a locked root account
(which from what I hear debian-installer will happily give you if
you don't enter a root password or something like that) you'll
be pretty much out of luck unless you can edit the kernel cmdline
and set init=/bin/sh.

Previous discussion concluded that using --force in rescue target
would be a good enough compromise. (And noone probably cares about
fixing sysvinit I presume?)

> 
> Should we have debian-installer create a drop-in for rescue.service to
> only add --force if during the installation no password was set for root?

That might be another (and better?) alternative...


It would probably also be good if we can find a nice place to document
what to do to handle this particular case when someone wants to
lock down their installation and make locked accounts really mean
locked.


HTH.

Regards,
Andreas Henriksson