Secure boot

[ghost]

You can sign GRUB or whatever bootloader you use and after that the UEFI will check the signature before loading it. The same way you can build a chain e.g. GRUB checkes the OS before loading it, the OS checks the applications before starting them, etc. I am currently researching the topic maybe there is a working solution we could add here. Afaik this should solve the rootkit problem and I guess it would harden the server as well. Would you add it to the description?

[imthenachoman]

Yes, I would add it to the document if you can tell me the steps?

[ghost]

Okay. I'll try to research it in the following days, maybe weeks and try it out on my microserver. I have found this so far: https://unix.stackexchange.com/questions/423666/secureboot-with-uefi-bootloader-and-grub2-only

[imthenachoman]

I too will look into this.

[ghost]

@imthenachoman Thanks!

[ghost]

I looked into this a little bit deeper recently: https://github.com/zfsonlinux/zfs/issues/9376 In theory with LUKS there is a tamper proof solution and it looks like I don't fully understand the boot process of encrypted systems. I'll read more in the topic. I decided to finish it off after many months of procrastination.

[noahbliss]

Unfortunately, secureboot doesn't go far enough on its own since it can 1. be disabled and 2. doesn't verify enough. I'd recommend taking a look at mortar for both more information and a solution. Good luck out there!~

[ghost]

@noahbliss Thanks! I'll check it. A read a lot more in the topix since october. Secure boot just verifies the boot loader, but if you want to verify the kernel, initrd, etc, then you have to have a boot loader that is capable of that. The rest of the system can be encrypted. I think this protects from an "evil maid", so she cannot add a keylogger for example when you are not home and she cannot copy and sell your data either. But she can still replace your keyboard or add a camera somewhere to get your password, so it is not 100% protection. If you add an SSH server to the boot loader, then you open up the system to MITM attack on the local network e.g. ARP poisoning, because the maid can access the private key of that SSH server. I guess there are a lot more MITM scenarios, so giving the key remotely is not the best option. Maybe adding some sort of hardware to store the key and ask for passphrase after power shortage is a good solution. I need to think about it.

[ghost]

I wrote a lot about what I found here: https://forums.freebsd.org/threads/what-kind-of-encryption-do-you-recommend.74474/#post-456003 But that is BSD. From Linux perspective I would recommend ZFS with native encryption because it increases the performance a lot compared to LUKS or GELI (in the case of BSD). It does not need to decrypt the blocks to verify the checksum and fix data corruption unlike LUKS or GELI.

[noahbliss]

@inf3rno you're absolutely right. The way I got around those issues was: Bootloader support solved by: No bootloader except the EFI-bootable linux kernel directly. Secureboot 1-file limit solved by: combining the cmdline, kernel, and initramfs into a single file then signing it. Secure key storage solved by: binding the luks key in the TPM module to PCRs 1 and 7 ensuring that secureboot is functioning, using our CA, and booting a file with a valid signature.

Happy to elaborate if you'd like. I actually use this model as a root-of-trust with extended filesystems from there. E.g. right now I have gocryptfs on btrfs with its key inside of /etc but /etc itself is in luks with its key in the TPM. So it all unrolls correctly. ^_^

All of this automated through upgrade hooks. Pretty convenient.

[ghost]

@noahbliss I think we should continue this in your repo. Maybe I can contribute somewhat. I am relative good at organizing code.

[hellresistor]

search about Devora project on gitlab. maybe have a start point :octocat:

[ihor-lev]

As far as I understand, a secure boot should help to prevent a break from a VM hosting provider (supervisor). But it may not be possible for some types of VM virtualizations (KVM?).

[hellresistor]

for a physical server control I suggest create a Pen-USB contains a bootloader with a encrypted keyfile with password to boot into HDD OS ;) Everytime you need reboot server, you need put the usb pen ;) else is "impossible" access to the encrypted partitions.

[noahbliss]

@hellresistor while that is absolutely more effective then not encrypting, It does have two major caveats.

One, the administrator will need to physically be with the server in event of a power reset, meaning a server could be down for potentially an extended period of time.

Two, there is no mechanism to verify integrity of the unencrypted boot data on the disk. You could more easily get around this by having the entire boot/ESP partition on your thumb drive, but I'd still then raise point 1 as a concern. There is also the very unlikely risk of duplication of the pendrive. Might seem paranoid but if you had multiple admins, there's no real way to know it hasn't been copied.

Not trying to shamelessly advertise, but mortar does fix both of these issues. :P

[hellresistor]

Not trying to shamelessly advertise, but mortar does fix both of these issues. :P

we both are talking different level of server control/access/paranoid, obviously ;) "shamelessly advertise" seems a bit rude words ;) (i have faith was a language spelling misunderstanding ^^ )

also, nice work! ;) will check that