[Utility Script] My take on a verified boot

After reading this and this i decided to try to make my system secure boot. I tried many variants, the sbctl probably the easiest, but i did not like the fact that i have to make unified kernels and most of all, that i had to put the kernel on the fat32 ESP or change the boot loader and load an ext4 efi driver.
So i started thinking, there must be another way to achieve this. The whole concept of (secure) verified boot should be to warn you if the boot files are changed. Nothing more actually. And if it warns you that something is off, you actually are already infected, because for the efi or kernel to be changed, something malicious had to have been run with root during the previous boot. So the only sensible option is to scan the disk from a live environment, and it does not really matter, if such infected system boots (as in my project) or stops booting as in the microsoft’s concept.

So having decided to go with hashes instead of signatures and to just warn, that make my future project with similar functionality but significantly easier to code. I just wanted a small script that hashes the most important files and tells me if the hashes do not match. The next thing was to choose how to hash. I wanted the thing to be light and fast. After some benchmark tests the fastest thing i managed to find was xxhash, which is also probably the only dependency that has to be additionally installed. It is not suitable for encryption, but it was damn fast - less than a second for 2-3 installed kernels. The last thing was to decide about the update algorithm after a kernel change. I decided to leave that a manual process. Of course it can be made set-and-forget with a pacman hook, but i thought, if a trojan is so sophisticated to update kernels, it would certainly be smart enough to disable the post-transaction hooks, because this is how the official sbctl works.

So, after all these considerations, i present you my little script for verified boot. It checks the hashes of all kernels it finds in /boot and all efi files it finds in /boot/efi. Note that if your efi is somewhere else you have to adjust it in the script. Also, i have hardcoded the name and location to /root/verifier.sh, if you save it somewhere else you have to change it in the service file. If you stick to the defaults, i have also included the update command in the latest update of my Cheatsheet.
If discrepancies are found, like updated grub or kernel, a pop up is shown and stays until clicked (and it is noted in the journal).

verifier

Here is the script. The needed systemd service file and instructions are inside at the comment section. And do not forget to make the file executable.

verifier.sh
#!/bin/bash
# Verified boot - compares hashes of efi and kernels against known values just like secure boot.
# If they differ you are notified on boot and can update the hashes
# Creator: Todor Uzunov 
# License: GNU - free like free speech and free beer for everybody!
# Version: 01.07.2024 0.2
# Changelog: logic rewrite - fixed the false negative in case of partial match
# 
# Dependencies: findutils, libnotify, xxhash, awk, tee
#
# Update hashes with:
# sudo xxhsum -H2 $(sudo find /boot/initramfs* /boot/vmlinuz* /boot/efi/ -type f) | sudo tee /root/.kernelhashes
# or just run "sudo /root/verifier.sh -update" argument
#
# Do not run manually with sudo without -update, you will get a false positive.
#
# If you get the message hashes differ you can run the following to see which hash from the list is different:
# sudo xxhsum -H2 -c /root/.kernelhashes
#
# Installing the service:
# sudo systemctl edit --force --full verifier.service
# select the service details below, paste with middle click, remove all # and exit with ctrl-x
#=======================================
#[Unit]
#Description=Boot Verifier
#[Service]
#User=root
#Group=root
#ExecStart=/root/verifier.sh
#[Install]
#WantedBy=graphical.target
#=======================================
# After the success message, restart the daemon and start the service:
# sudo systemctl daemon-reload
# sudo systemctl start verifier.service
# sudo systemctl status verifier.service
# sudo systemctl enable verifier.service

ec=1

if [[ "$1" == "-update" ]]; then
sudo xxhsum -H2 $(sudo find /boot/initramfs* /boot/vmlinuz* /boot/efi/ -type f) | sudo tee /root/.kernelhashes
else
sleep 34
fi

displ=":$(ls /tmp/.X11-unix/* | sed 's#/tmp/.X11-unix/X##' | head -n 1)"
usr=$(who | grep '('$displ')' | awk '{print $1}' | head -n 1)
uid=$(id -u $usr)

xxhsum -H2 -c /root/.kernelhashes; ec=$?
if [[ $ec == 0 ]] ; then 
echo "Verified hashsums for boot files match OK"
# sudo -u $usr DISPLAY=$displ DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$uid/bus notify-send -u normal "Kernel hashsums" "verified OK"
else
echo "Verified hashsums for boot files do not match, you have updated or you are infected"
echo "If you want to update the hashes run /root/verifier.sh -update" #running from root, no sudo
sudo -u $usr DISPLAY=$displ DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$uid/bus notify-send -u critical -i utilities-terminal_su "Kernel hashsums differ, you either just updated or you are infected" "If you want to update the hashes run sudo /root/verifier.sh -update" #running from user, sudo here 
fi

If you were infected, wouldn’t it be possible that your script would be useless as the infection could just adjust the hashes to not trigger any warning?

Whilst this is possible, surely the rogue program would need to know where to look for these?

I think someone able to hack you may have some knowledge.

1 Like

Yes indeed. No way around that. At least i made it so that it requires root. So a malicious script from home cannot change it. A root script yes.

Exactly my idea. Security through obscurity (yes i know i am also against it but better than nothing). As long as this project stays relatively unpopular the payloads will not be programmed to detect it.

This is only made with the idea to detect some popular automated script in the wild, if such thing ever occurs. It is in no way intended to protect against human hackers.

Anyway it’s cool to have fun project but I would not feel more secure at all with it :smiley:

It is a fun project. And it is always better NOT to catch a virus, instead of detecting it afterwards. This is the same controversy as with the real “secure boot” and that is why a lot of people think it is useless (not to mention it has the side effect of giving too much control to some corporations).

1 Like