It just occurred to me the issue with using smartcards/yubikeys/multifactor for logging into a qubes system.
If login happens on dom0, and dom0 has no access to usb since usb is in sys-usb, and I don’t believe that the sys-usb qube has been started till after login, I don’t see how we’d be able to use smartcards, or biometrics or similar since I believe they all use USB.
It would be possible to put usb back in dom0 (which has obvious security problems)
It might be possible to start sys-usb before login (possibly by creating a new “start qube automatically on boot and before login” option for qubes similar to the current “start qube automatically on boot” option )
However, even if we did that, forwarding the usb device to dom0 seems like a bad idea.
How would we get the authentication information back to dom0 in a safe way?
Start from a hardware root of trust where the key signs that.
Heads Firmware - your BIOS/firmware is validated by your hardware attestation device and TPM chip to not be tampered with.
Heads firmware stage 2 - your /boot partition is GPG signed by your hardware attestation device to be not tampered with with.
Heads firmware stage 3 - ask for your password and use that, with TPM chip, to unlock the decryption key to your storage drive/OS drive. Luks, thank you.
edit ive removed some irrelevant content which was not relevant to your question and was more about me venting
in case my understanding is wrong, please let me reconfirm,
so do you mean that,
the BIOS authentication and Luks decryption,
happen between the Yubikey and TPM chip ?
and does not happen betwen Yubikey and sys-usb or dom0 ?
Have hide all usb kernel option, so your usb drive, usb keyboard, etc, will not work. It mean, your yubikey will not work for luks encryption or qubes login.
qubesctl state.sls qvm.usb-keyboard
All usb controller will work before sys-usb is started + auto enable keyboard to dom0 after running.
The reason I had scoped the question to the login screen is that I was only interested in what potential there was of extending qubes to multi-user.
(The answer ends up being that multi-user is already planned though having multiple sys-gui qubes.)
idk if this correct
but how does this make sense when you are decrypting disk using a software that on the part of the disk that encrypted?
the bootloader is the only thing not encrypted and
dom0 is encrypted (right?)
so this should happen between grub (bootloader) and yubikey
okay, if grub / bootloader is not firmware,
then is it part of Qubes OS ?
which is not being encrypted by Luks, and being used for booting after BIOS only ?
If anyone is still curious about how Qubes OS does all of that decryption stuff on boot, all of that is in the initial ramdisk that accompanies the kernel on the boot partition.
The kernel is a single binary program that always runs whatever is in it.
When you build it, depending on what you are building it for (a mainframe or a toaster), you might want certain parts of the kernel running all the time, or running only when needed, to save system resources. In this case, these parts of the kernel are created as modules.
A fully-loaded 5.19 kernel with all the stuff baked into the actuall kernel instead of modules (the vmlinuz file in /boot) is well over 2GB, it would be incredibly stupid to have that big a file in your boot partition, not to mention having it chew up 2GB of your RAM simply by having your machine powered-on…
So you build a “barebones” kernel with just the things that you know your machine will need all the time. This is why the Qubes OS dom0 kernel is <10MB
So where’s the rest of it, then?
It’s all stored in /lib/modules
But how does the kernel load these modules if my disk is encrypted…?
There’s another file called the initial ramdisk (the initramfs*.img file in /boot) that contains the kernel modules required to boot the machine. When GRUB loads the kernel, it also puts the initial ramdisk into the system’s RAM.
So the modules needed to decrypt the hard drive (the sexy Plymouth boot splash screen, the algorithms, the method of decryption, YubiKey drivers, etc.) are all already in the RAM before you even enter your password
I hope that I have expanded someone’s knowledge of how a computer boots