GNU bug report logs -
#72889
Support for root filesystem on btrfs raid1 on two LUKS devices
Previous Next
To reply to this bug, email your comments to 72889 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#72889
; Package
guix
.
(Fri, 30 Aug 2024 08:49:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"amano.kenji" <amano.kenji <at> proton.me>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Fri, 30 Aug 2024 08:49:04 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Imagine that root filesystem is btrfs raid1 on two LUKS devices.
To mount it on initial ram disk, guix has to first unlock two LUKS devices with one password.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#72889
; Package
guix
.
(Thu, 05 Sep 2024 01:58:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 72889 <at> debbugs.gnu.org (full text, mbox):
I guess this is going to require passphrase reuse for mapped devices.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#72889
; Package
guix
.
(Tue, 10 Sep 2024 13:15:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 72889 <at> debbugs.gnu.org (full text, mbox):
- /dev/sda
/dev/sda1: A tiny LUKS partition that's filled with the content of a keyfile without any filesystem format.
/dev/sda2: /boot for grub. It also serves as FAT32 EFI partition.
- /dev/sdb
/dev/sdb1: /gnu/store on btrfs raid1
/dev/sdb2: / on btrfs raid1 on LUKS
- /dev/sdc
/dev/sdc1: /gnu/store on btrfs raid1
/dev/sdc2: / on btrfs raid1 on LUKS
Open /dev/sda1 as a luke device, /dev/mapper/key, with one password. It contains a keyfile without any filesystem format. Use /dev/mapper/key as a keyfile for all other LUKS devices in mapped devices.
This exposes /gnu/store, but /gnu/store is not supposed to have any sensitive data. This obviously makes it practically impossible to detect physical tempering of data, but if you store it at a secure location, you don't have to worry too much about evil maid attack.
RAID1 for physically secure servers is enough to ensure some availability when a disk fails.
For laptops that you carry, you are not going to use btrfs raid1, and you can just have unencrypted /boot on fat32 and / on btrfs on luks. extra-initrd contains a keyfile for / so that I don't have to type the password twice.
A desktop computer doesn't require server-level availability, but people who have money can still put root on encrypted btrfs raid1.
Perhaps, can this be documented in the cook book?
This bug report was last modified 339 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.