Hello!
I have an idea about how modern linux should work with encrypted LUKS partitions.
Le 08/03/2023 à 16:28, Alexey Kuznetsov a écrit :
Hello!
I have an idea about how modern linux should work with encrypted LUKS
partitions.
Hi,
I'm using LUKS for a long time on both my personal (desktop) and
professional (laptop) computers. Since they are single user (me), I
use autologin in the display manager, lightdm in my case. Because
there is only one slot configured in LUKS, I'm sure this is me, so
lightdm can autologin safely.
However, you are proposing to solve the case for multiple user
computers. In that case, I would think about a much simpler design:
- Remember which slot was used to unlock the LUKS root partition
- Make a map with slot -> user to autologin
- Autologin that user on boot
No more passing password, no more password update headache. But only a
root user can update the map "slot -> user".
Adrien
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?
Hi Alexey,
2023-03-08 16:45 CET, Alexey Kuznetsov:
Right now on a system encrypted with LUKS, the first prompt you'll seeis a
grub passphrase to unlock the device, after OS boot you see a secondprompt
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 atthe
same time?
I disable the login password by connecting my user automatically on my
LUKS setup. It is a few clicks away in most DEs I would guess.
Did you consider this instead of implementing what you propose?
Bests,
Agathe.
Le 08/03/2023 à 16:28, Alexey Kuznetsov a écrit :
Hello!
I have an idea about how modern linux should work with encrypted LUKS partitions.
Hi,
I'm using LUKS for a long time on both my personal (desktop) and
professional (laptop) computers. Since they are single user (me), I use autologin in the display manager, lightdm in my case. Because there is only one slot configured in LUKS, I'm sure this is me, so lightdm can autologin safely.
However, you are proposing to solve the case for multiple user computers.
In that case, I would think about a much simpler design:
- Remember which slot was used to unlock the LUKS root partition
- Make a map with slot -> user to autologin
- Autologin that user on boot
No more passing password, no more password update headache. But only a
root user can update the map "slot -> user".
Adrien
1) grub can ask for a login/password, then MD5 the text and unlock the LUKSForget about this part: encrypted /boot/ is pointless from a security
Can you explain or refer to literature why encrypted /boot is[...]
pointless?
Disk encryption is great (when properly implemented) to protect
sensitive information on your machine from prying eyes if it gets
stolen, but unless you're putting sensitive data in /boot why go to the
added trouble of encrypting it?
Encryption per se does not protect against modification, I am aware of
that. That is even more true for disk encryption where the encrypted
data block has to fit into the physical disk block, so there is no room
for a MAC or signature. However, in combination with a filesystem like
btrfs which checksums everything, it is providing some protection, even though it was not designed for that purpose.
Apart from the fact that UEFI Secure Boot is an overly complex monster
which is basically broken[1] by design, my understanding of it is also
that it does not protect configs, initramfs etc. in /boot. It only
protects the kernel image and loaded modules.
[1] https://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/
In addition, files in /boot like the initrd are generated individually
and may contain files not limited to what someone puts into /boot intentionally. In contrast to /boot/efi, /boot does not only contain
static files delivered by the distribution.
Apart from the fact that UEFI Secure Boot is an overly complex monsterIt can, with an appropriate configuration.
which is basically broken[1] by design, my understanding of it is also
that it does not protect configs, initramfs etc. in /boot. It only
protects the kernel image and loaded modules.
In addition, files in /boot like the initrd are generated individuallyIn the future the initramfs will (usually) be static as well.
and may contain files not limited to what someone puts into /boot intentionally. In contrast to /boot/efi, /boot does not only contain
static files delivered by the distribution.
Okay, so you're wanting to rely on encrypted /boot as an incomplete alternative to checking file signatures, because the currentNo, this is not about blind modification. There are relevant attacks in
attestation solutions are also imperfect. Keep in mind that
checksumming isn't providing protection from coherent modification
of the decrypted filesystem and checksums, it's just protecting
against someone blindly modifying the encrypted blocks.
If they haveThe only thing an attacker can modify in software is the GRUB binary in /boot/efi. The GRUB binary can be more easily verified by Secure Boot
physical access to your system sufficient to modify firmware or add
hardware without you noticing, then encrypted /boot is pretty
pointless against such an actor.
Well, it's not as if encrypted /boot is protecting you from theHardware modifications are not a fair comparison. Hardware
attacks described in that article either. Someone with that level of
access to your system can quite easily record/copy your decryption
keys, or simply wait until you've unlocked your sensitive data.
Sure, if you're concerned that sensitive information is being put inWhat additional work? The installer did it automatically without me
/boot sufficient to warrant the additional work of protecting it
from disclosure when someone steals the device or gets their handsAny installed program that is not in the essential setup should be
on the drive after disposal, then by all means go ahead. It's just
not usually worth that amount of additional complexity.
It comes down to basic cost/benefit analysis, and deciding whatThere is nothing inconvenient about it.
threats you reasonably want to invest in defending against. I'm
certainly not saying there's *never* a reason to encrypt /boot, but
people who feel they need to do so aren't involved in improving
tools and automation sufficiently to make it convenient to set up
either.
In the future the initramfs will (usually) be static as well.
On Fri, 2023-03-10 at 15:12 +0100, Marco d'Itri wrote:Due to multiple reasons, mostly related to secure boot and boot
In the future the initramfs will (usually) be static as well.Can you provide more information on that?
On Wed, Mar 8, 2023 at 7:11 PM Adrien CLERC <adrien@antipoul.fr> wrote:
Le 08/03/2023 à 16:28, Alexey Kuznetsov a écrit :Right. But you still have to remember passpharse and your main account password. This is not about autologin. This is about unlocking your machine LUKS with only login/password without having an additional passphrase to remember.
Hello!
I have an idea about how modern linux should work with encrypted LUKS
partitions.
Hi,
I'm using LUKS for a long time on both my personal (desktop) and
professional (laptop) computers. Since they are single user (me), I use
autologin in the display manager, lightdm in my case. Because there is only >> one slot configured in LUKS, I'm sure this is me, so lightdm can autologin >> safely.
However, you are proposing to solve the case for multiple user computers.
In that case, I would think about a much simpler design:
- Remember which slot was used to unlock the LUKS root partition
- Make a map with slot -> user to autologin
- Autologin that user on boot
No more passing password, no more password update headache. But only a
root user can update the map "slot -> user".
Adrien
The reason you can not use Login/Password as the LUKS passphrase
is because The Passphrase can not be different for different
users. The passphrase is not simply a password but instead it is
part of the key material used to decrypt and encrypt.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 339 |
Nodes: | 16 (2 / 14) |
Uptime: | 00:06:16 |
Calls: | 7,466 |
Calls today: | 2 |
Files: | 12,691 |
Messages: | 5,627,862 |