[10:48] <teddy-dbear> Morning peoples, critters and everything else
[14:40] <ChinnoDog> Anyone booting with /boot on an encrypted partition?
[14:57] <icey> ahoy
[15:25] <jthan> ChinnoDog: I do
[15:25] <jthan> Wait
[15:25] <jthan> I have
[15:25] <jthan> I don't anymore because it was a pita and not worth it
[15:25] <jthan> because chances are nothing on /boot is /that/ important anyway
[15:28] <icey> jthan: I think the idea behind encrypting /boot is to protect the OS area, ie: if I get ahold of your computer and you haven't gotten /boot encrypted, I could muck with the environment itself
[15:29] <jthan> but if / is still encrypted
[15:29] <jthan> your data is protected still
[15:29] <icey> until I give you a bad kernel?
[15:29] <ChinnoDog> That and it is annoying to randomly run out of space on /boot
[15:29] <jthan> What's a bad kernel going to do?
[15:29] <ChinnoDog> Also if you use btrfs snapshots and root is a separate partition then reverting to a previous snapshot will not revert your kernel
[15:29] <jthan> ugh don't use btrfs yet. lol
[15:30] <ChinnoDog> In any case, what do you have to do to get grub to boot from your encrypted partition?
[15:30] <ChinnoDog> I think the problem is that it won't load cryptodisk because running "ls" at the grub prompt doesn't show they decrypted block device
[15:31] <jthan> ChinnoDog:     linux   /vmlinuz-linux root=UUID=f3a0f99b-56ac-495b-98e1-2ec2c160b008 rw cryptdevice=/dev/sda2:cryptroot quiet
[15:32] <jthan> however it depends which method to encrypt it in the first place you used
[15:32] <ChinnoDog> That is the boot string but it doesn't seem to work when I enable cryptodisk in /etc/defaults/grub
[15:32] <jthan> icey: You can give me a bad kernel but my data is still safe and that's more important to me.
[15:33] <icey> jthan: until you boot my malicious thing and get your data that way?
[15:33] <jthan> icey: your malicious thing is still going to decrypt my /?
[15:33] <jthan> ChinnoDog: jonathan@karma:~$ cat /etc/default/grub | grep -i crypt
[15:33] <jthan> GRUB_CMDLINE_LINUX="cryptdevice=/dev/sda2:cryptroot"
[15:33] <ChinnoDog> Did that
[15:33] <jthan> that's all I've got
[15:33] <ChinnoDog> hmm
[15:33] <jthan> and it Just Works(TM)
[15:33] <icey> jthan: ideally, you don't know it's malicious and you decrypt it yourself ;-)
[15:34] <jthan> icey: Yeah, but if someone had their hands on my laptop the last thing I'm going to do is log in. However, I'm curious if you're referring to a specific exploit or have done this
[15:34] <ChinnoDog> I tried to do it with Ubuntu 16.04 at install. Chrooted to disk after installation and made those modifications but it doesn't work. I guess I will have to debug it further.
[15:35] <jthan> I always setup my partitioning and encrypted volumes and then install
[15:35] <jthan> idk how flexible the Ubuntu installer is
[15:35] <icey> jthan: haven't, just considering the theoretical reason for encrypted /boot; do you mean that you would reformat the device if somebody else had unrestricted access to your machine for ...say 10 minutes?
[15:35] <ChinnoDog> jthan: What if a boot sector virus patches your /boot before grub loads?
[15:35] <jthan> icey: nobody would, first of all. But second of all, what's low level enough that you're going to be able to use entirely system calls that will send you my password
[15:35] <jthan> Which, btw, is a one-use password
[15:35] <jthan> I just think you're proposing something that isn't actually plausible.
[15:36] <icey> jthan: how do you encrypt the device with an OTP?
[15:36] <jthan> Not "one time"
[15:36] <jthan> I said one use
[15:36] <jthan> it's the only place that password is used.
[15:36] <icey> ah, cool
[15:36] <jthan> So you could get it, but unless you're on my laptop again it's a no go
[15:36] <jthan> but I also VERY highly doubt anyone would be on my laptop without me sitting there
[15:37] <jthan> and if they were, I'm dead and no longer care, but still encourage anyone to try.
[15:37] <jthan> There are a lot of measures in place on $worklaptop to protect me and my data
[17:03] <r00t^2> icey: there are boot-time verifiers that attempt to mitigate evil maid attacks as well, i.e. https://github.com/grazzolini/mkinitcpio-chkcryptoboot