Package Details: mkinitcpio-chkcryptoboot 0.0.6-1

Git Clone URL: (read-only, click to copy)
Package Base: mkinitcpio-chkcryptoboot
Description: This hook checks for a modified bootloader code, in an encrypted boot setup, and warns the user to not enter his root device password
Upstream URL:
Keywords: boot check grub security
Licenses: BSD
Submitter: grazzolini
Maintainer: grazzolini
Last Packager: grazzolini
Votes: 10
Popularity: 0.000000
First Submitted: 2015-03-12 18:53 (UTC)
Last Updated: 2019-04-30 01:23 (UTC)

Latest Comments

grazzolini commented on 2016-03-28 06:01 (UTC)

@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 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]

belette commented on 2016-03-26 10:10 (UTC)

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

grazzolini commented on 2015-09-28 14:10 (UTC)

@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

commented on 2015-09-25 23:47 (UTC)

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.

grazzolini commented on 2015-06-23 13:40 (UTC)

@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.

debwoo commented on 2015-06-23 04:05 (UTC)

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.

grazzolini commented on 2015-05-13 19:04 (UTC)

@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.

EscapedNull commented on 2015-05-13 17:11 (UTC)

@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.

grazzolini commented on 2015-05-12 15:50 (UTC)

@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: 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.

grazzolini commented on 2015-05-11 13:22 (UTC)

@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.

EscapedNull commented on 2015-05-08 23:46 (UTC)

This wiki edit ( brought to my attention that GRUB's core.img (stage-2) is not stored in the first 440 bytes, and thus is not checked by mkinitcpio-chkcryptoboot. Is this true? And should chkcryptoboot be updated to check core.img as well as the stage-1 MBR code?

EscapedNull commented on 2015-04-02 12:46 (UTC)

Kernel parameter checking works. I'm afraid firmware hashing is beyond my knowledge. I wouldn't be surprised if the more advanced APIs were vendor-specific, so it may become an ongoing effort to create a tool that is compatible with all of them. Such a tool would definitely be helpful in making this hook more secure, though.

grazzolini commented on 2015-03-31 17:27 (UTC)

@EscapedNull As of yesterday, version 0.0.2 implements the kernel parameter checking. Of course it doesn't prevent you from typing your root password on a compromised machine, but it possibly warn you that you encrypted boot partition wasn't used to unlock your root partition. As I mentioned, all these things are to increase the complexity and prevent you from being the low hanging fruit. I am looking at how to create a hash of your bios nvram and hd firmware. But it is hard to even find decent documentation on these topics, let alone a tool to do that. Looks like I am gonna have to implement one.

EscapedNull commented on 2015-03-31 10:33 (UTC)

@grazzolini Thanks for the explanation of the kernel parameter. I'll test it out once it is implemented. I'm not sure how much security this provides, though, because the root password is required in order to boot from the root filesystem, and if that is known, then all bets are off. I only posted that patch here because it's so small and is somewhat cosmetic, but I'll get involved on Github as soon as I can. I don't own any (U)EFI machines, so I can't test secure boot in a real environment. All of my testing has been done with QEMU using the OVMF firmware, which probably does allow any key to sign EFI stubs, I just don't know how to do that yet. I also have to look into some of the other security technologies that you mentioned. Thanks for writing this hook and for all of the work you do!

grazzolini commented on 2015-03-27 15:03 (UTC)

@EscapedNull Everything that increases the odd of an attacker being detected should be done. Specially these days. So, BIOS firmware hash/checksuming, hard drive firmware hashing, are all things that could be done to detect attacks. And this is nice, because since your boot partition is encrypted the attacker have to assume you have all these checks in place, therefore, increasing the complexity and detectability of these attacks. I also have big plans for this hook.

grazzolini commented on 2015-03-27 14:57 (UTC)

@EscapedNull The CMDLINE_NAME and CMDLINE_VALUE is a name=value pair to detect if your encrypted boot partition was bypassed or not. It can be anything, preferably two hashes, something unique to you. That only you could manufacture. That way the encrypted root partition can detect if it was booted from the intended encrypted boot partition or not. It's not working yet, but in the next version will. As for the diff, if it is possible, could you create a pull request on github? I am focusing development there. As for UEFI secureboot, if your bios allows you to reset the keys, it can be used, sure. I am using in my machine. But it your bios only allows microsoft keys, then you need to disable secureboot. Other security measures should complement this, such as a TPM chip, STARK, pepper, tresor, etc. Think of this as something like your last line of defense. There are obvious attacks on this, specifically, if your bootloader was compromised and the attacker has knowledge that you are using this hook, it can try to tamper with it's checking and display a false message. This could be improved in the future, but it will be always a mouse and cat game.

EscapedNull commented on 2015-03-27 13:20 (UTC)

I'm not sure what to set CMDLINE_NAME and CMDLINE_VALUE to. I guess something like CMDLINE_NAME=('root' 'cryptdevice') CMDLINE_VALUE=('UUID=...' '/dev/disk/by-uuid/...') but I don't know how one would specify flags (which have no name, like "rw"), or what advantage this has over a flat comparison of the full kernel cmdline. I also don't know what attacks this protects against, since kernel parameters are stored in /boot/grub/grub.cfg and all bets are off if the /boot partition is compromised anyway. I wrote a small patch that prints the time at which the hash was originally computed, which might help the user decide whether or not to enter the root passphrase (e.g. forgot to run mkinitcpio after grub-install). 10a11 > echo "Checksum was computed at $(stat -c '%y' disk-head.sha256)" 22a24 > echo "Checksum was computed at $(stat -c '%y' /etc/chkcryptoboot/efistub.sha256)" I was also wondering if you could explain how UEFI "secure boot" relates to all of this? For example, is it conceivable that we could generate an EFI stub signing key, have the user manually add it to his firmware, then use it to sign the EFI stub during the install hook? Or would that defeat the purpose of secure boot? I'm just curious if secure boot could complement this hook in any way. I have some big plans for this hook, for example scanning the hardware (PCI bus, USB bus, CPU, disk serial numbers, firmware version, etc) at install time and comparing them at boot time. There's only so much that can be accomplished securely using only software, but if each thing raises the bar just a little bit, then why not? As it is now, I feel much safer than previously using an unencrypted /boot. Keep up the good work!