FS#70408 - [mkinitcpio] Add hook for unlocking root account

Attached to Project: Arch Linux
Opened by Nils (nlswrnr) - Sunday, 11 April 2021, 11:05 GMT
Last edited by Jelle van der Waa (jelly) - Monday, 18 September 2023, 17:44 GMT
Task Type Bug Report
Category Arch Projects
Status Closed
Assigned To Christian Hesse (eworm)
Giancarlo Razzolini (grazzolini)
Morten Linderud (Foxboron)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 7
Private No

Details

Description:

Right now the root account is locked in the initramfs. Locking root makes sense in most situations, but when working on early boot code like initramfs hooks, it prevents access to the emergency shell and therefore helpful logs.

Attached you will find a patch that adds a `shadow` hook that overwrites the `/etc/shadow` file in the initramfs with the one from the actual main OS, effectively unlocking the root account with the same password as the main OS. This hook should only be enabled when debugging other initramfs hooks, and should otherwise remain disabled.
This task depends upon

Closed by  Jelle van der Waa (jelly)
Monday, 18 September 2023, 17:44 GMT
Reason for closing:  Moved
Additional comments about closing:  https://gitlab.archlinux.org/archlinux/m kinitcpio/mkinitcpio/issues/205
Comment by Michel Koss (MichelKoss1) - Sunday, 11 April 2021, 13:05 GMT
If you need emergency shell in initramfs then it's usually too late to add a hook and rebuild initramfs so having such option may no be much useful. There is "init=/bin/sh" cmdline parameter which allows you to have working root terminal inside initramfs even when your boot process is broken.
Comment by Nils (nlswrnr) - Sunday, 11 April 2021, 13:37 GMT
Yes, this is more a precautionary hook that I enabled when playing around with other hooks.

I a few kernel parameters, like `systemd.debug_shell` and `emergency`, and none of them worked, but I didn't try `init=/bin/sh`. If it really works even before the root FS has been mounted, then this hook is indeed useless.
Comment by Doug Newgard (Scimmia) - Sunday, 11 April 2021, 13:44 GMT
"If it really works even before the root FS has been mounted"

It doesn't.
Edit:rdinit= would, but that also bypasses everything init in the initrd does, so it's not as useful.
Comment by loqs (loqs) - Sunday, 11 April 2021, 15:15 GMT Comment by Michel Koss (MichelKoss1) - Sunday, 11 April 2021, 16:08 GMT
@Scimmia I'm pretty sure it worked in the past when I used it to fix my broken boot process. Even Arch wiki documents it[1]. Has it changed recently? Or do you mean it doesn't work when systemd hook is used (I don't know about that one).

[1] https://wiki.archlinux.org/index.php/General_troubleshooting#Recovery_shells

Side note: I don't really get what locking root account in initramfs achieves in terms of system security.
Comment by Giancarlo Razzolini (grazzolini) - Sunday, 11 April 2021, 17:31 GMT
mkinitcpio already has break=premount and break=postmount. I'm not sure what unlocking the root account achieves.
Comment by Jose L. Pereira (GaKu999) - Sunday, 11 April 2021, 17:46 GMT
@grazzolini Does that work in a systemd based initramfs?

That aside, one can write a simple sd-shadow hook that reintroduces the shadow.initramfs behavior with ease, this would be useful to debug a systemd initramfs by reading the journals and such that would otherwise be lost after reboot, but that is all there is to it.

For the standard busybox it's just useless tho, since it doesn't care what shadow has to say.
Comment by Doug Newgard (Scimmia) - Sunday, 11 April 2021, 22:06 GMT
MichelKoss1, all of that is done post-initramfs
Comment by Morten Linderud (Foxboron) - Monday, 12 April 2021, 07:40 GMT
I had the samme issue yesterday trying to figure out why Switch root wasn't happening in the systemd initrd. I like the `sd-shadow` and the `shadow` hooks.

The main issue with "break=premount' and "break=postmount" is that the when you do non-trivial boot setups, like with UEFI stubs, you can't edit the kernel cmdline if there is a regression in anything initrd related. This leaves you in a pickle if you could solve it with a shell but have that refused. Rebuilding the UEFI executable for the "break=" parameters is a bit annoying compared to having the root account unlockable if needed.
Comment by loqs (loqs) - Monday, 12 April 2021, 20:24 GMT
@Foxboron are you suggesting the none systemd initrd switch to using sulogin instead of exec sh to start a rescue shell which would then have the same behavior as the systemd initrd.
If so the code systemd uses to create minimal passwd, shadow and group files could be made common and reused?
Then there is the question of does whatever unlocks the root account need to copy the system's shadow to the initrd or is it sufficient to unlock the root account with an empty password or roots current password?
Comment by Jose L. Pereira (GaKu999) - Tuesday, 13 April 2021, 06:53 GMT
EDIT: this was quite verbose and useless, fixed it now with something more proper.

@loqs that is the best approach, to make busybox based use sulogin and reuse code for passwd group and shadow.
Next a shadow hook that will do the [1]old behavior of /etc/shadow.initramfs or locked.
Finishing with an announcement so everyone catches up the news, and add the shadow hook if wanted.

This makes both initramfs implementations equal in that sense, and the shadow hook will work on both.

...

Now, to the reason for the [2]revert, how frequent can the initramfs spontaneously fail that an unlocked root is a bad idea?
I really can't replicate that danger under normal circumstances, typically it will succeed always or fail always when something is wrong...
If something bad in the system can cause systemd based to spontaneously fail, I wouldn't be surprised that it would also cause the busybox based one to fail as well.

[1] https://github.com/archlinux/svntogit-packages/commit/7952a4228333c57926884fbd49526a8cfe2eaea1
[2] https://github.com/archlinux/svntogit-packages/commit/776743d220cbb56e9abca2cc8bcef3a0ab7c8d0a
Comment by Michel Koss (MichelKoss1) - Wednesday, 14 April 2021, 10:28 GMT
As I understand this bugreport is about inability to get shell access in systemd hook while initramfs is broken therefore making busybox which doesn't have such issue working the same is off the rail.

I dislike the idea of having root password hash leaked in initramfs same as I dislike the idea of having to boot from livecd when initramfs breaks because it was decided debugging it from the inside impossible. I think asking people to rebuild their initramfs when they can't boot isn't helpful but I don't mind if systemd hook users are satisfied with it as long as busybox is untouched.
Comment by Morten Linderud (Foxboron) - Wednesday, 14 April 2021, 12:31 GMT
The solution in practice is to just have `FILES=(/etc/shadow.initramfs)`. But it would be better to have something standardized. I don't see *why* you'd be disclosing any root password checksum if the files are separate.

@loqs I think it's weird they use two different systems, yes. But I'd rather just want `shadow` to include `/etc/shadow.initramfs` and leave the other details for the busybox implementation.

Comment by loqs (loqs) - Wednesday, 14 April 2021, 13:56 GMT
Add eworm to the FS to elaborate on the shortcomings that required [1]?
If this hook is currently going to only apply to systemd should it not be provided by the systemd package instead of mkinitcpio?

[1] https://github.com/archlinux/svntogit-packages/commit/776743d220cbb56e9abca2cc8bcef3a0ab7c8d0a
Comment by Michel Koss (MichelKoss1) - Wednesday, 14 April 2021, 14:39 GMT
@Foxboron the idea of using real root shadow contents is circulating in comments as potential solution and it's what hook attached to this FS does. Separate shadow file doesn't have such issue but apparently it has other shortcomings (arguably not the most informative commit description).
Comment by David Runge (dvzrv) - Thursday, 20 July 2023, 16:56 GMT
It's been some time. It would be really good to find a solution to this, as in the UKI scenario the status quo is maximum pain.
Comment by Buggy McBugFace (bugbot) - Tuesday, 08 August 2023, 19:11 GMT
This is an automated comment as this bug is open for more then 2 years. Please reply if you still experience this bug otherwise this issue will be closed after 1 month.
Comment by Tim Ruffing (realorrandom) - Monday, 21 August 2023, 07:55 GMT
@bugbot still relevant

Loading...