Allow logging in to rescue/emergency shell as root
In Qubes OS guests, the console is always the Xen console. There are never untrusted entities with access to this under any circumstances. The only supported way to get access to this from a VM is the admin.vm.Console service, which is (by design) equivalent to root access in the destination VM.
Therefore, set SYSTEMD_SULOGIN_FORCE=1 to tell systemd-sulogin-shell to pass --force to sulogin(8). Since the root account is locked in Qubes VMs, this causes sulogin(8) to allow login as root without a password.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 70.57%. Comparing base (
1783677) to head (ecdb763). Report is 29 commits behind head on main.
Additional details and impacted files
@@ Coverage Diff @@
## main #526 +/- ##
=======================================
Coverage 70.57% 70.57%
=======================================
Files 3 3
Lines 469 469
=======================================
Hits 331 331
Misses 138 138
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Should those drop-ins be included in initramfs (when generated in VM) too? Or maybe they already are there?
Should those drop-ins be included in initramfs (when generated in VM) too? Or maybe they already are there?
Yes, they should. Dracut module?
19:36:45 [qb.build_rpm.core-agent-linux.vm-fc40.build] DEBUG: RPM build errors:
19:36:45 [qb.build_rpm.core-agent-linux.vm-fc40.build] DEBUG: error: File not found: /builddir/build/BUILDROOT/qubes-core-agent-4.3.11-1.1.fc40.x86_64/usr/lib/dracut/modules.d/99qubes/module-setup.sh
Should this be conditional on the VM not being sys-usb? sys-usb might get an untrusted USB serial port plugged into it.
Should this be conditional on the VM not being
sys-usb?sys-usbmight get an untrusted USB serial port plugged into it.
Similar issue may apply to other VM too. Can you make it specifically for hvc0 console only instead?
Should this be conditional on the VM not being
sys-usb?sys-usbmight get an untrusted USB serial port plugged into it.
But actually does other consoles matter here? Isn't rescue/emergency started only on the primary console (as configured with console= kernel param)?
Should this be conditional on the VM not being
sys-usb?sys-usbmight get an untrusted USB serial port plugged into it.But actually does other consoles matter here? Isn't rescue/emergency started only on the primary console (as configured with
console=kernel param)?
It should be indeed. I can check.
Should this be conditional on the VM not being
sys-usb?sys-usbmight get an untrusted USB serial port plugged into it.But actually does other consoles matter here? Isn't rescue/emergency started only on the primary console (as configured with
console=kernel param)?It should be indeed. I can check.
Addressed much more simply by explicitly setting /dev/hvc0 as the terminal path.
I'd like to have a test for this feature, I can write one, but I need few primitives for it:
- how to break the boot in initramfs stage, preferably without involving the default 2min (?) timeout for rootfs mount
- how to break the boot after initramfs (mask some unit via kernel cmdline? remove some file?)
I'd like to have a test for this feature, I can write one, but I need few primitives for it:
- how to break the boot in initramfs stage, preferably without involving the default 2min (?) timeout for rootfs mount
rd.rescue or rd.emergency on kernel command line with an in-VM kernel.
- how to break the boot after initramfs (mask some unit via kernel cmdline? remove some file?)
rescue or emergency on kernel command line, with either dom0-provided or in-VM kernel.
I tested this.
I've (finally) written a test for this (will open a PR in a moment). Summary of running it:
- works fine with Fedora 41 xfce template and dom0-provided kernel
- is unnecessary with Fedora 41 xfce template and in-vm kernel for emergency mode in initramfs (this one gives shell already, without any of the changes here)
- doesn't work with Debian 12 xfce template (still says "Cannot open access to console, the root account is locked")
- adding
rd.emergencyto kernel cmdline on Debian doesn't trigger emergency shell in initrd at all (with in-vm kernel), so I don't know if it works or if it's necessary
I haven't ran the test on Whonix yet, I guess results will be similar to Debian.
@marmarek friendly ping