Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Full-Disk encryption with boot - LVM on LUKS
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Installing Gentoo
View previous topic :: View next topic  
Author Message
Viatorus
n00b
n00b


Joined: 22 Jul 2016
Posts: 17

PostPosted: Tue Dec 27, 2016 12:53 pm    Post subject: Full-Disk encryption with boot - LVM on LUKS Reply with quote

Hello,

I try to install gentoo (plasma/systemd) on a laptop with full disk encryption including the boot partition.

After a fresh install and reboot, the screen hangs on:
Quote:
GRUB


What I have:
Code:
(chroot) livecd / # lsblk
NAME          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda             8:0    0   477G  0 disk 
└─sda1          8:1    0   477G  0 part 
  └─lvm       253:0    0   477G  0 crypt
    ├─vg-root 253:1    0   100G  0 lvm   /
    └─vg-home 253:2    0   377G  0 lvm   /home

Code:
(chroot) livecd / # cat /etc/fstab
# <fs>         <mountpoint>   <type>      <opts>      <dump/pass>

# NOTE: If your BOOT partition is ReiserFS, add the notail option to opts.
/dev/mapper/vg-root      /      ext4      noatime      0 1
/dev/mapper/vg-home      /home      ext4      noatime      0 2


Code:
(chroot) livecd / # cat /etc/default/grub
...
GRUB_CMDLINE_LINUX="init=/usr/lib/systemd/systemd cryptdevice=/dev/sda1:lvm dolvm crypt_root=UUID=1234*1234:vg-root root=/dev/mapper/vg-root"
GRUB_ENABLE_CRYPTODISK=1
GRUB_PRELOAD_MODULES="lvm cryptodisk luks"
...


Code:
genkernel --lvm --luks initramfs --menuconfig all


I enabled lvmetad via systemd.

Code:
(chroot) livecd / #  grub-install /dev/sda
Installing for i386-pc platform.
  /run/lvm/lvmetad.socket: connect failed: No such file or directory
  WARNING: Failed to connect to lvmetad. Falling back to internal scanning.
File descriptor 3 (pipe:[62060]) leaked on vgs invocation. Parent PID 16041: grub-install
  /run/lvm/lvmetad.socket: connect failed: No such file or directory
  WARNING: Failed to connect to lvmetad. Falling back to internal scanning.
  Volume group "lvm" not found
  Cannot process volume group lvm
...
grub-install: error: disk `lvm/vg-root' not found.

Code:
(chroot) livecd / # grub-mkconfig -o /boot/grub/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/kernel-genkernel-x86_64-4.4.39-gentoo
Found initrd image: /boot/initramfs-genkernel-x86_64-4.4.39-gentoo
  /run/lvm/lvmetad.socket: connect failed: No such file or directory
  WARNING: Failed to connect to lvmetad. Falling back to internal scanning.
File descriptor 3 (pipe:[62199]) leaked on vgs invocation. Parent PID 16189: /usr/sbin/grub-probe
  /run/lvm/lvmetad.socket: connect failed: No such file or directory
  WARNING: Failed to connect to lvmetad. Falling back to internal scanning.
  Volume group "lvm" not found
  Cannot process volume group lvm
  /run/lvm/lvmetad.socket: connect failed: No such file or directory
  WARNING: Failed to connect to lvmetad. Falling back to internal scanning.
/usr/sbin/grub-probe: error: disk `lvm/vg-root' not found.
done



Any advice what to do?
Back to top
View user's profile Send private message
frostschutz
Advocate
Advocate


Joined: 22 Feb 2005
Posts: 2970
Location: Germany

PostPosted: Tue Dec 27, 2016 1:05 pm    Post subject: Reply with quote

try GRUB_ENABLE_CRYPTODISK=y instead of =1

Encrypted boot complicates things a lot with zero benefits.
Back to top
View user's profile Send private message
Viatorus
n00b
n00b


Joined: 22 Jul 2016
Posts: 17

PostPosted: Tue Dec 27, 2016 1:12 pm    Post subject: Reply with quote

Thank you for your hint. It doesn't change anything.

Curiously, setting GRUB_ENABLE_CRYPTODISK=y/1 and commenting out GRUB_ENABLE_CRYPTODISK does not change /boot/grub/grub.cfg at all.
Back to top
View user's profile Send private message
frostschutz
Advocate
Advocate


Joined: 22 Feb 2005
Posts: 2970
Location: Germany

PostPosted: Tue Dec 27, 2016 1:36 pm    Post subject: Reply with quote

Viatorus wrote:
Curiously, setting GRUB_ENABLE_CRYPTODISK=y/1 and commenting out GRUB_ENABLE_CRYPTODISK does not change /boot/grub/grub.cfg at all.


It should change the grub core image (meaning you have to grub-install to make the change effective). The grub core image contains the modules as support partitions, filesystems, technologies that allow grub access to the /boot partition and its grub.cfg in the first place...

If the grub.cfg is already encrypted and grub core image not able to reach through the encryption then it's kinda irrelevant what's in the config... it can never be read.

In terms of security it doesn't add anything... grub can just as well be tampered with as an unencrypted boot partition, and you can suffer from keyloggers etc. A lot of complexity for nothing, IMHO (and that's not considering how badly documented that grub cryptodisk feature is)


Also check which useflags you have active for grub? It might need device-mapper enabled and stuff.
Back to top
View user's profile Send private message
R0b0t1
Apprentice
Apprentice


Joined: 05 Jun 2008
Posts: 255

PostPosted: Wed Dec 28, 2016 2:52 pm    Post subject: Reply with quote

Hello,

If you don't mind me making a suggestion inferring from the problem you are experiencing - you would probably be best served by carrying around your /boot on a flash drive. When doing this I would recommend using an initramfs instead of relying on GRUB to decrypt your disk as it is more configurable and allows you to recover the system when something is messed up. Your system would still be susceptible to evil maid attacks, and that can only be remedied by having your system on your person at all times.

Your question as asked has likely already been answered - what you want to do is impossible. You will need to have /boot, or at least the partition containing GRUB, unencrypted. You can make it resistant to tampering using secure boot. You may want to refer to https://wiki.gentoo.org/wiki/Sakaki's_EFI_Install_Guide/Configuring_Secure_Boot. Should you go that route, I would invite you to consider using an EFI stub loader built into the kernel, though this can make your boot process inflexible.
Back to top
View user's profile Send private message
frostschutz
Advocate
Advocate


Joined: 22 Feb 2005
Posts: 2970
Location: Germany

PostPosted: Wed Dec 28, 2016 5:16 pm    Post subject: Reply with quote

I'm very happy with an USB flash drive (+ encrypted keyfiles and several livecds on it) myself. This flash drive can be removed from the system as soon as it's booted (you only need it for booting, and for updating kernels, I guess) so you can take it with you everywhere you go, so it'll be hard to tamper with.

R0b0t1 wrote:
When doing this I would recommend using an initramfs instead of relying on GRUB to decrypt your disk as it is more configurable and allows you to recover the system when something is messed up.


You have to use initramfs either way. GRUB decrypts for itself to reach the kernel image and initramfs, then the kernel boots and has to do its own decryption... so you have to unlock the LUKS container twice unless you put the master key into the initramfs - which would be a bit strange.
Back to top
View user's profile Send private message
Twenty_Four
n00b
n00b


Joined: 10 Apr 2015
Posts: 9

PostPosted: Wed Dec 28, 2016 6:05 pm    Post subject: Reply with quote

Do you have grub compiled with device-mapper use flag enabled? I have almost the same setup as you working perfectly.
Back to top
View user's profile Send private message
R0b0t1
Apprentice
Apprentice


Joined: 05 Jun 2008
Posts: 255

PostPosted: Wed Dec 28, 2016 7:02 pm    Post subject: Reply with quote

Taking it out is a good idea, as it prevents a malicious program from stealing your key.

frostschutz wrote:
I'm very happy with an USB flash drive (+ encrypted keyfiles and several livecds on it) myself. This flash drive can be removed from the system as soon as it's booted (you only need it for booting, and for updating kernels, I guess) so you can take it with you everywhere you go, so it'll be hard to tamper with.

R0b0t1 wrote:
When doing this I would recommend using an initramfs instead of relying on GRUB to decrypt your disk as it is more configurable and allows you to recover the system when something is messed up.


You have to use initramfs either way. GRUB decrypts for itself to reach the kernel image and initramfs, then the kernel boots and has to do its own decryption... so you have to unlock the LUKS container twice unless you put the master key into the initramfs - which would be a bit strange.


There is a setting that fairly transparently passes off to a Linux kernel without an initrd if I am remembering correctly but it is fairly recent. I admit to never having used it, mostly for reasons that lead me to recommend against it, but it seems to work for some. I suspect it requires the Linux kernel to play along - all I know is the last time I tried anything remotely similar (automated disk decryption facilities in genkernel) it failed spectacularly.
Back to top
View user's profile Send private message
stikonas
n00b
n00b


Joined: 25 Mar 2012
Posts: 4

PostPosted: Thu Jan 12, 2017 5:39 pm    Post subject: Reply with quote

R0b0t1 wrote:
Hello,

If you don't mind me making a suggestion inferring from the problem you are experiencing - you would probably be best served by carrying around your /boot on a flash drive. When doing this I would recommend using an initramfs instead of relying on GRUB to decrypt your disk as it is more configurable and allows you to recover the system when something is messed up. Your system would still be susceptible to evil maid attacks, and that can only be remedied by having your system on your person at all times.

Your question as asked has likely already been answered - what you want to do is impossible. You will need to have /boot, or at least the partition containing GRUB, unencrypted. You can make it resistant to tampering using secure boot. You may want to refer to https://wiki.gentoo.org/wiki/Sakaki's_EFI_Install_Guide/Configuring_Secure_Boot. Should you go that route, I would invite you to consider using an EFI stub loader built into the kernel, though this can make your boot process inflexible.


Well, it's still not fully safe against evil maid attack but makes it much more complicated. Evil maid can find same looking hardware and insert drive from your laptop to bypass secure boot. But encrypting /boot makes it much more secure. In fact I use this setup with my own secure boot keys. Luks key is then stored in initramfs for secure decryption (this is safe since initramfs is encrypted). Well, root can read the key but root can obtain LUKS master key anyway.
Back to top
View user's profile Send private message
Roman_Gruber
Advocate
Advocate


Joined: 03 Oct 2006
Posts: 3806
Location: Austro Bavaria

PostPosted: Thu Jan 12, 2017 6:27 pm    Post subject: Reply with quote

Quote:

Well, it's still not fully safe against evil maid attack but makes it much more complicated. Evil maid can find same looking hardware and insert drive from your laptop to bypass secure boot. But encrypting /boot makes it much more secure. In fact I use this setup with my own secure boot keys.


I also run for years luks based notebooks. boot is not encrypted. the setup is like in the gentoo handbook. just an initramfs and another way to mount root thats it.

you can carry around an usb flash drive with your boot on it, as already noted.

The commetns about it makes it more secure when you encrypt also /boot is just nonsense.

When you really want secure hardware you should go for an open source bios box. And than you have the issues with microcode cpus, hidden cpus in the chipsets, hidden stuff in other components and such!

No one really knows whats in those chipsets these days, hidden cpu features.

for your personal computer, it should be sufficient to have /boot not encrypted, and jsut hash the hole /boot partition when you want to!

ASUS for example. I am an ASUS user mostly, does not provide me any schematics for their hardware, or any specs for their additional buttons, closed source their custom tools and such, windows only bios updaters and such. Just a big black box, with a locked down bios.


---

Good luck in finding a bootloader which can handle encrypted boot. You most probably end at an unencrypted boot anyway, is it on your harddrive or on an usb pendrive or somewhere else.

Additionaly you also use SYSTEMD, which is hardly proven to be stable. That introduces also errors, as others similar components are proven to work with luks for example (=> initramfs + eudev + OPENRC + gentoo-sources)

--

Quote:
Evil maid can find same looking hardware and insert drive from your laptop to bypass secure boot. ... bla bla bla


Just make the point clear, which I may read behind the lines.

luks is just an additional layer.

When I take your drive in an external case and mount it with the proper keyphrase, regardless how i would get that keyphrase, I have full access to the data of that luks "partion".

--

A secure box also means, running only bare minimum.
A secure box means also running software which is trusted and less prone to errors. SYSTEMD is definitely not in that area.

Less software, less bugs, less components to backup, smaller drives, cheaper backups, faster backups

I have cut down my software over the years, the number of installed packages, to a bare minimum over the past few years.
KDE / GNOME is full of bugs without any additional benefit for running "software" for daily work, e.g. webbrowser, office software and such.
Back to top
View user's profile Send private message
R0b0t1
Apprentice
Apprentice


Joined: 05 Jun 2008
Posts: 255

PostPosted: Thu Jan 12, 2017 9:05 pm    Post subject: Reply with quote

Roman_Gruber wrote:
Quote:

Well, it's still not fully safe against evil maid attack but makes it much more complicated. Evil maid can find same looking hardware and insert drive from your laptop to bypass secure boot. But encrypting /boot makes it much more secure. In fact I use this setup with my own secure boot keys.


I also run for years luks based notebooks. boot is not encrypted. the setup is like in the gentoo handbook. just an initramfs and another way to mount root thats it.

you can carry around an usb flash drive with your boot on it, as already noted.

The commetns about it makes it more secure when you encrypt also /boot is just nonsense.

When you really want secure hardware you should go for an open source bios box. And than you have the issues with microcode cpus, hidden cpus in the chipsets, hidden stuff in other components and such!

No one really knows whats in those chipsets these days, hidden cpu features.

for your personal computer, it should be sufficient to have /boot not encrypted, and jsut hash the hole /boot partition when you want to!

ASUS for example. I am an ASUS user mostly, does not provide me any schematics for their hardware, or any specs for their additional buttons, closed source their custom tools and such, windows only bios updaters and such. Just a big black box, with a locked down bios.


While I don't mean to derail the topic too far, I would suggest anyone who reads this far in the thread to look at the POWER8 (and the yet-to-be-released POWER9) architectures. This is the only modern architecture on par with x86_64 that is completely open. It even has a programmable supervisory chip a la Intel's Management Engine or AMD's Platform Security Processor. There is a CrowdSupply (https://www.crowdsupply.com/raptor-computing-systems/talos-secure-workstation) for funding a workstation based upon it, but, unfortunately, as of today (1/12/2017), with two days left, it looks as if it will not reach its funding goal. The only other option are servers produced by IBM or RackSpace, as other vendors used closed motherboards.

Many of the processors supported by the linux-sunxi project (https://linux-sunxi.org/Main_Page) are also open. Most ARM processors have a mechanism similar to the Management Engine or Platform Security Processor with unstated capabilities. Interested parties should check the libreboot project every once in a while for active crowd funding campaigns.

As an aside, the failure of the Talos funding campaign was saddening as it seems x86 alternatives are still a decade out. I had much interest in the management processor and lower-level IO system programming. The servers which exist currently are around $10,000 as a baseline.

Roman_Gruber wrote:

A secure box also means, running only bare minimum.
A secure box means also running software which is trusted and less prone to errors. SYSTEMD is definitely not in that area.

Less software, less bugs, less components to backup, smaller drives, cheaper backups, faster backups

I have cut down my software over the years, the number of installed packages, to a bare minimum over the past few years.
KDE / GNOME is full of bugs without any additional benefit for running "software" for daily work, e.g. webbrowser, office software and such.


Broadly I agree, but I think this understates the importance of open hardware. Most faults in software can be corrected to a reasonable degree of certainty if the hardware can be expected to behave.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Installing Gentoo All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum