Arch Linux User Repository

@belette This hook can be used on any kind of setup, even if you don't have anything encrypted, it will try to detect changes to your boot loader. But, for this to be the most effective, you need a separate boot partition, on top of your existing, unencrypted, ESP partition, with a different password from your root partition. See [1] for an explanation. In the end it all depends on your threat model. If you want to have everything under /, them perhaps just using https://aur.archlinux.org/packages/chkboot/ would suffice for you. It will warn you of changes under /boot and, since you are mounting your ESP partition under /boot/efi, will also detect changes to your boot loader. chkboot and chkcryptoboot can be used in conjunction (the tendency is that they'll be merged into one single package in the future). [1] https://wiki.archlinux.org/index.php/Dm-crypt/Specialties#Technical_Overview

Hi I have used your package in the past where I add a separate boot partition. Now and thanks to Grub I got only an EFI partition and a / partition included everything (boot as well) and I mount my EFI partition on /boot/efi I read that for this package to be relevant boot needs to be an a different partition, can you tell me a little bit more about this please? Do you think having only one encrypted / including everything is an issue in term of security? many thanks for your inputs

@xor Hello xor. I don't think there is a need for quoting when comparing the strings. There is quoting on the first if, because test otherwise won't work. But in the second if, where we compare the strings, I'm not comparing if CMDLINE_NAME=CMDLINE_VALUE. I'm comparing the whole thing with the parameter from the kernel command line. If there was a need for a quote, it would be to encompass the whole thing: "$CMDLINE_NAME=$CMDLINE_VALUE". You can test if the profile alert is working, by changing either the CMDLINE_NAME or CMDLINE_VALUE, to be different from your kernel cmdline. Then, you just need to source the profilealert script and see if it warns. Also, if you detect any bugs in the code, if possible, please report it as an issue on github. Pull requests are welcome! Cheers

If I'm right about, there are couple of minor quoting mistakes. This is my solution. if [ -n "$CMDLINE_NAME" -a -n "$CMDLINE_VALUE" ]; then #checks if the name value pair was configured and checks for them in the kernel's cmdline read "z" < /proc/cmdline for param in "$z" ; do if [ "$param" = "$CMDLINE_NAME"="$CMDLINE_VALUE" ]; then return 0 fi done fi I recommend to recommend quoting the config options in mkinitcpio-chkcryptoboot.install. Correct me if I'm wrong.

@debwoo In a BIOS-GPT setup, if your disk has a protective MBR (which is the default, AFAIK), this hook will keep working the same as if you were using a BIOS-MBR setup Unfortunately, this hook doesn't (yet) protects GRUB's second stage (core.img). The other protections are still valid, such as the bypass detection. I'm working on this, but since the second stage can be on a lot of places around the disk, it's hard to determine it, without hacking into GRUB itself. On UEFI setups, the efi stub created by GRUB already has all the modules he needs to unlock the encrypted boot partition and read the configuration from it. That's why, right now, only in UEFI setups you will get the full benefits from this hook.

I am interested in testing this on my older machine using BIOS-GPT approch. From the config file it apprears to not be possible. And from comments here I can make out that this will not work on BIOS-GPT boot and system encrypted install.

@EscapedNull If I somehow can know beforehand the size of the core.img module and where it was installed, then these problems would vanish. The only way I know of doing that right know is to wrap around the grub-install command. I can try to guess and/or allow these values to be configurable. This is what I didn't figured out yet. In the UEFI case, yes, the stub is hashed regardless if it contains the configuration embedded or not. I just personally think it's a dumb idea to embed the configuration on it. I'm planning of merging this package into chkboot and making everything more functional. Perhaps I can improve both.

@grazzolini I'm glad you're aware of the problem and looking into possible solutions. For MBR, hashing the entire gap is the only feasible solution I can think of given my limited knowledge of the grub-install process. Personally I'm less concerned about boot time than security, but I realize that they are both important to consider. For BIOS-GPT, I'm wondering if it could be as simple as using grub-mkimage to dump core.img, find out the contents (hash) and length from that, then we're only left with determining the start location on the disk (intuition says the first byte at the beginning of the BIOS boot partition). As for UEFI, perhaps I'm misunderstanding you, but aren't we already hashing the EFI stub as a whole, regardless of embedded modules and grub.cfg? This sounds like the simplest case, because it is stored as a file rather than a segment of raw bytes. That's just my two cents, but ultimately I trust your opinion more than mine.

@EscapeNull To make things even worse, when using BIOS with GPT the core.img file is embedded on the bios boot partition, which does not have a file system. Also, when using UEFI one can have the dumb idea of embedding grub.cfg and the modules on the efi stub, see: https://wiki.archlinux.org/index.php/GRUB#GRUB_standalone. I am truly concerned with all this and I'm analyzing the best approach for dealing with this. But it seems to me that I'll probably need to mess with the grub installation process itself.

@EscapedNull Yes, it is true. core.img is embedded on the gap between MBR and the first partition. The issue here is, from what I read about the documentation, it's size can vary. I'd had to figure out the size of core.img or just hash the entire gap. The problem is, that this gap can be as big as 1MB. So it will introduce some (more) delay in the boot process. I am analyzing the best approach.