Hello! I have an idea about how modern linux should work with encrypted LUKS partitions.
Right now on a system encrypted with LUKS, the first prompt you'll see is a grub passphrase to unlock the device, after OS boot you see a second prompt for login/password. This looks redundant. How about bypassing the second prompt and allowing grub to handle all security prompts including the login/password and unlocking the LUKS at the same time? It can be done with few steps: 1) grub can ask for a login/password, then MD5 the text and unlock the LUKS device using this MD5 passphrase: md5(login+password) or using a simple plain(login+password) string. 2) grub passing this information (login/password) to the kernel. 3) Kernel boots and passing (or password manager service, which can be part of systemd) reads that data from kernel (/proc/cmdline) and rewrites it (hide for security reasons). 4) password manager (systemd service) makes login manager (gdm) auto login with provided data and unlocking session (gnome) keyring. 5) if the user updates the password (passwd, chpasswd), then the password manager updates LUKS corresponding slot with md5(login+password) or plain(login+password) passphrase. Since LUKS1 supports 8 keys, we can support only 8 logins which can open a drive and automatically login to the system. Also password manager has to associate every user (UID) with LUKS device UUID and slot number for simple key updates.Another option: we can use one SLOT0 or masterkey with a different technique for encrypting keys and storing all users in the encrypted list on ESP partition, this option has no user count limits. I'm using full disk encryption (including /boot), except the ESP (/boot/efi) partition for grub.img and other EFI binaries). Theoretically it can work with legacy grub (stage2 compiled using modules and grub.cfg (right?) which can be used to specify how we should unlock the device using passphrase or login/password) and the EFI option can read all configs from grub.cfg. This is major changes to the linux password management. Can it be improved and proposed as standard? -- AK
