Allow logging in to rescue/emergency shell as root #526
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
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 ☔ View full report in Codecov by Sentry. |
|
Should those drop-ins be included in initramfs (when generated in VM) too? Or maybe they already are there? |
Yes, they should. Dracut module? |
DemiMarie
force-pushed
the
sulogin-force
branch
2 times, most recently
from
757ef06 to
9e612aa
Compare
|
DemiMarie
force-pushed
the
sulogin-force
branch
from
9e612aa to
958f43d
Compare
|
Should this be conditional on the VM not being |
Similar issue may apply to other VM too. Can you make it specifically for hvc0 console only instead? |
But actually does other consoles matter here? Isn't rescue/emergency started only on the primary console (as configured with |
It should be indeed. I can check. |
DemiMarie
force-pushed
the
sulogin-force
branch
from
958f43d to
af904b8
Compare
Addressed much more simply by explicitly setting |
DemiMarie
force-pushed
the
sulogin-force
branch
2 times, most recently
from
e9dc9ed to
7043815
Compare
DemiMarie
force-pushed
the
sulogin-force
branch
2 times, most recently
from
45bd08f to
f9c1fdf
Compare
|
I'd like to have a test for this feature, I can write one, but I need few primitives for it:
|
|
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. Other consoles, such as a USB serial console, are not supported as domU consoles under Qubes OS. 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. Use TTYPath= to enforce that the console is, in fact, the Xen console and not some other console, in case the assumption in the previous paragraph turns out false for some reason. This will break if the Xen drivers are not included in the guest kernel config, but an HVM guest with Qubes tools but no Xen drivers is not a supported configuration.
DemiMarie
force-pushed
the
sulogin-force
branch
from
f9c1fdf to
ecdb763
Compare
|
I tested this. |
|
I've (finally) written a test for this (will open a PR in a moment). Summary of running it:
|
|
I haven't ran the test on Whonix yet, I guess results will be similar to Debian. |
It shouldn't prompt for the password, as the root account is locked. Related to QubesOS/qubes-core-agent-linux#526
It shouldn't prompt for the password, as the root account is locked. Related to QubesOS/qubes-core-agent-linux#526
It shouldn't prompt for the password, as the root account is locked. Related to QubesOS/qubes-core-agent-linux#526
2 participants
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.