heads/initrd/bin/gui-init

361 lines
13 KiB
Plaintext
Raw Normal View History

#!/bin/sh
# Boot from a local disk installation
CONFIG_BOOT_GUI_MENU_NAME='Heads Boot Menu'
. /etc/functions
. /tmp/config
mount_boot()
{
# ensure default boot device is set
if [ ! -e "$CONFIG_BOOT_DEV" ]; then
if (whiptail $CONFIG_ERROR_BG_COLOR --clear --title "ERROR: $CONFIG_BOOT_DEV missing!" \
--yesno "The /boot device $CONFIG_BOOT_DEV could not be found!\n\nYou will need to configure the correct device for /boot.\n\nWould you like to configure the /boot device now?" 30 90) then
config-gui.sh
fi
# Mount local disk if it is not already mounted
elif ! grep -q /boot /proc/mounts ; then
mount -o ro /boot
if [ $? -ne 0 ]; then
if (whiptail $CONFIG_ERROR_BG_COLOR --clear --title 'ERROR: Cannot mount /boot' \
--yesno "The /boot partition at $CONFIG_BOOT_DEV could not be mounted!\n\nWould you like to configure the /boot device now?" 30 90) then
config-gui.sh
else
recovery "Unable to mount /boot"
fi
fi
fi
}
Add GUI package update handler w/ checksum update function Part of the Heads workflow involves handling legitimate changes to /boot as part of the package manager. This is a challenging workflow to handle as package managers on many systems work in a completely unattended way (and some even reboot first, apply updates, and then reboot again). We need to be able to detect changes that are potentially caused by a package manager so to do that I've set up a trigger within the OS (currently just for Debian) that runs both before and after package updates. It verifies the signatures in /boot and if they fail before package updates it creates a log file in /boot/kexec_package_trigger_pre.txt. If they fail after package updates run /boot/kexec_package_trigger_post.txt is created. These files contain the following fields: CHANGED_FILES: A list of files in /boot that failed the sha256sum check UPDATE_INITRAMFS_PACKAGE: An (optional) list of packages known to trigger initramfs changes Following those fields is a list of log output from the last package manager run which contains its own formatted fields (I'm pulling from /var/lib/dpkg/info). When a user selects a boot option, gui-init first verifies the checksums just to catch errors before calling kexec-select-boot. If there are any errors it looks for these package logs and if they exist, it displays appropriate warnings. If the files are absent it displays a more generic warning. The user is also given an opportunity to re-sign the /boot hashes.
2018-04-03 22:20:34 +00:00
verify_global_hashes()
{
# Check the hashes of all the files, ignoring signatures for now
check_config /boot force
TMP_HASH_FILE="/tmp/kexec/kexec_hashes.txt"
TMP_PACKAGE_TRIGGER_PRE="/tmp/kexec/kexec_package_trigger_pre.txt"
TMP_PACKAGE_TRIGGER_POST="/tmp/kexec/kexec_package_trigger_post.txt"
if cd /boot && sha256sum -c "$TMP_HASH_FILE" > /tmp/hash_output ; then
return 0
elif [ ! -f $TMP_HASH_FILE ]; then
if (whiptail $CONFIG_ERROR_BG_COLOR --clear --title 'ERROR: Missing Hash File!' \
--yesno "The file containing hashes for /boot is missing!\n\nIf you are setting this system up for the first time, select Yes to update\nyour list of checksums.\n\nOtherwise this could indicate a compromise and you should select No to\nreturn to the main menu.\n\nWould you like to update your checksums now?" 30 90) then
prompt_update_checksums
Add GUI package update handler w/ checksum update function Part of the Heads workflow involves handling legitimate changes to /boot as part of the package manager. This is a challenging workflow to handle as package managers on many systems work in a completely unattended way (and some even reboot first, apply updates, and then reboot again). We need to be able to detect changes that are potentially caused by a package manager so to do that I've set up a trigger within the OS (currently just for Debian) that runs both before and after package updates. It verifies the signatures in /boot and if they fail before package updates it creates a log file in /boot/kexec_package_trigger_pre.txt. If they fail after package updates run /boot/kexec_package_trigger_post.txt is created. These files contain the following fields: CHANGED_FILES: A list of files in /boot that failed the sha256sum check UPDATE_INITRAMFS_PACKAGE: An (optional) list of packages known to trigger initramfs changes Following those fields is a list of log output from the last package manager run which contains its own formatted fields (I'm pulling from /var/lib/dpkg/info). When a user selects a boot option, gui-init first verifies the checksums just to catch errors before calling kexec-select-boot. If there are any errors it looks for these package logs and if they exist, it displays appropriate warnings. If the files are absent it displays a more generic warning. The user is also given an opportunity to re-sign the /boot hashes.
2018-04-03 22:20:34 +00:00
fi
return 1
else
CHANGED_FILES=$(grep -v 'OK$' /tmp/hash_output | cut -f1 -d ':')
# if files changed before package manager started, show stern warning
if [ -f "$TMP_PACKAGE_TRIGGER_PRE" ]; then
PRE_CHANGED_FILES=$(grep '^CHANGED_FILES' $TMP_PACKAGE_TRIGGER_POST | cut -f 2 -d '=' | tr -d '"')
TEXT="The following files failed the verification process BEFORE package updates ran:\n${PRE_CHANGED_FILES}\n\nCompare against the files Heads has detected have changed:\n${CHANGED_FILES}\n\nThis could indicate a compromise!\n\nWould you like to update your checksums anyway?"
Add GUI package update handler w/ checksum update function Part of the Heads workflow involves handling legitimate changes to /boot as part of the package manager. This is a challenging workflow to handle as package managers on many systems work in a completely unattended way (and some even reboot first, apply updates, and then reboot again). We need to be able to detect changes that are potentially caused by a package manager so to do that I've set up a trigger within the OS (currently just for Debian) that runs both before and after package updates. It verifies the signatures in /boot and if they fail before package updates it creates a log file in /boot/kexec_package_trigger_pre.txt. If they fail after package updates run /boot/kexec_package_trigger_post.txt is created. These files contain the following fields: CHANGED_FILES: A list of files in /boot that failed the sha256sum check UPDATE_INITRAMFS_PACKAGE: An (optional) list of packages known to trigger initramfs changes Following those fields is a list of log output from the last package manager run which contains its own formatted fields (I'm pulling from /var/lib/dpkg/info). When a user selects a boot option, gui-init first verifies the checksums just to catch errors before calling kexec-select-boot. If there are any errors it looks for these package logs and if they exist, it displays appropriate warnings. If the files are absent it displays a more generic warning. The user is also given an opportunity to re-sign the /boot hashes.
2018-04-03 22:20:34 +00:00
# if files changed after package manager started, probably caused by package manager
elif [ -f "$TMP_PACKAGE_TRIGGER_POST" ]; then
LAST_PACKAGE_LIST=$(grep -E "^(Install|Remove|Upgrade|Reinstall):" $TMP_PACKAGE_TRIGGER_POST)
UPDATE_INITRAMFS_PACKAGE=$(grep '^UPDATE_INITRAMFS_PACKAGE' $TMP_PACKAGE_TRIGGER_POST | cut -f 2 -d '=' | tr -d '"')
if [ "$UPDATE_INITRAMFS_PACKAGE" != "" ]; then
TEXT="The following files failed the verification process AFTER package updates ran:\n${CHANGED_FILES}\n\nThis is likely due to package triggers in$UPDATE_INITRAMFS_PACKAGE.\n\nYou will need to update your checksums for all files in /boot.\n\nWould you like to update your checksums now?"
else
TEXT="The following files failed the verification process AFTER package updates ran:\n${CHANGED_FILES}\n\nThis might be due to the following package updates:\n$LAST_PACKAGE_LIST.\n\nYou will need to update your checksums for all files in /boot.\n\nWould you like to update your checksums now?"
fi
else
TEXT="The following files failed the verification process:\n${CHANGED_FILES}\n\nThis could indicate a compromise!\n\nWould you like to update your checksums now?"
fi
if (whiptail $CONFIG_ERROR_BG_COLOR --clear --title 'ERROR: Boot Hash Mismatch' --yesno "$TEXT" 30 90) then
prompt_update_checksums
Add GUI package update handler w/ checksum update function Part of the Heads workflow involves handling legitimate changes to /boot as part of the package manager. This is a challenging workflow to handle as package managers on many systems work in a completely unattended way (and some even reboot first, apply updates, and then reboot again). We need to be able to detect changes that are potentially caused by a package manager so to do that I've set up a trigger within the OS (currently just for Debian) that runs both before and after package updates. It verifies the signatures in /boot and if they fail before package updates it creates a log file in /boot/kexec_package_trigger_pre.txt. If they fail after package updates run /boot/kexec_package_trigger_post.txt is created. These files contain the following fields: CHANGED_FILES: A list of files in /boot that failed the sha256sum check UPDATE_INITRAMFS_PACKAGE: An (optional) list of packages known to trigger initramfs changes Following those fields is a list of log output from the last package manager run which contains its own formatted fields (I'm pulling from /var/lib/dpkg/info). When a user selects a boot option, gui-init first verifies the checksums just to catch errors before calling kexec-select-boot. If there are any errors it looks for these package logs and if they exist, it displays appropriate warnings. If the files are absent it displays a more generic warning. The user is also given an opportunity to re-sign the /boot hashes.
2018-04-03 22:20:34 +00:00
fi
return 1
fi
}
prompt_update_checksums()
Add GUI package update handler w/ checksum update function Part of the Heads workflow involves handling legitimate changes to /boot as part of the package manager. This is a challenging workflow to handle as package managers on many systems work in a completely unattended way (and some even reboot first, apply updates, and then reboot again). We need to be able to detect changes that are potentially caused by a package manager so to do that I've set up a trigger within the OS (currently just for Debian) that runs both before and after package updates. It verifies the signatures in /boot and if they fail before package updates it creates a log file in /boot/kexec_package_trigger_pre.txt. If they fail after package updates run /boot/kexec_package_trigger_post.txt is created. These files contain the following fields: CHANGED_FILES: A list of files in /boot that failed the sha256sum check UPDATE_INITRAMFS_PACKAGE: An (optional) list of packages known to trigger initramfs changes Following those fields is a list of log output from the last package manager run which contains its own formatted fields (I'm pulling from /var/lib/dpkg/info). When a user selects a boot option, gui-init first verifies the checksums just to catch errors before calling kexec-select-boot. If there are any errors it looks for these package logs and if they exist, it displays appropriate warnings. If the files are absent it displays a more generic warning. The user is also given an opportunity to re-sign the /boot hashes.
2018-04-03 22:20:34 +00:00
{
if (whiptail --title 'Update Checksums and sign all files in /boot' \
--yesno "You have chosen to update the checksums and sign all of the files in /boot.\n\nThis means that you trust that the files in /boot have not been tampered with.\n\nYou will need your GPG key to continue and this change will modify your disk.\n\nDo you want to continue?" 16 90) then
update_checksums
Add GUI package update handler w/ checksum update function Part of the Heads workflow involves handling legitimate changes to /boot as part of the package manager. This is a challenging workflow to handle as package managers on many systems work in a completely unattended way (and some even reboot first, apply updates, and then reboot again). We need to be able to detect changes that are potentially caused by a package manager so to do that I've set up a trigger within the OS (currently just for Debian) that runs both before and after package updates. It verifies the signatures in /boot and if they fail before package updates it creates a log file in /boot/kexec_package_trigger_pre.txt. If they fail after package updates run /boot/kexec_package_trigger_post.txt is created. These files contain the following fields: CHANGED_FILES: A list of files in /boot that failed the sha256sum check UPDATE_INITRAMFS_PACKAGE: An (optional) list of packages known to trigger initramfs changes Following those fields is a list of log output from the last package manager run which contains its own formatted fields (I'm pulling from /var/lib/dpkg/info). When a user selects a boot option, gui-init first verifies the checksums just to catch errors before calling kexec-select-boot. If there are any errors it looks for these package logs and if they exist, it displays appropriate warnings. If the files are absent it displays a more generic warning. The user is also given an opportunity to re-sign the /boot hashes.
2018-04-03 22:20:34 +00:00
else
echo "Returning to the main menu"
fi
}
update_totp()
{
echo "Scan the QR code to add the new TOTP secret"
/bin/seal-totp
if [ -x /bin/libremkey_hotp_verification ]; then
echo "Once you have scanned the QR code, hit Enter to configure your Librem Key"
read
/bin/seal-libremkey
else
echo "Once you have scanned the QR code, hit Enter to reboot"
read
fi
/bin/reboot
}
# enable USB to load modules for external kb
enable_usb
# ensure /boot is sane and mount it
mount_boot
last_half=X
while true; do
MAIN_MENU_OPTIONS=""
MAIN_MENU_BG_COLOR=""
unset totp_confirm
# detect whether any GPG keys exist in the keyring, if not, initialize that first
GPG_KEY_COUNT=`gpg -k 2>/dev/null | wc -l`
if [ $GPG_KEY_COUNT -eq 0 ]; then
whiptail $CONFIG_ERROR_BG_COLOR --clear --title "ERROR: GPG keyring empty!" \
2018-12-12 22:09:19 +00:00
--menu "ERROR: Heads couldn't find any GPG keys in your keyring.\n\nIf this is the first time the system has booted,\nyou should add a public GPG key to the BIOS now.\n\nIf you just reflashed a new BIOS, you'll need to add at least one\npublic key to the keyring.\n\nIf you have not just reflashed your BIOS, THIS COULD INDICATE TAMPERING!\n\nHow would you like to proceed?" 30 90 4 \
'G' ' Add a GPG key to the running BIOS' \
'i' ' Ignore error and continue to default boot menu' \
'x' ' Exit to recovery shell' \
2>/tmp/whiptail || recovery "GUI menu failed"
totp_confirm=$(cat /tmp/whiptail)
fi
if [ "$totp_confirm" = "i" -o -z "$totp_confirm" ]; then
# update the TOTP code every thirty seconds
date=`date "+%Y-%m-%d %H:%M:%S"`
seconds=`date "+%s"`
half=`expr \( $seconds % 60 \) / 30`
if [ "$CONFIG_TPM" = n ]; then
TOTP="NO TPM"
elif [ "$half" != "$last_half" ]; then
last_half=$half;
TOTP=`unseal-totp`
if [ $? -ne 0 ]; then
whiptail $CONFIG_ERROR_BG_COLOR --clear --title "ERROR: TOTP Generation Failed!" \
--menu "ERROR: Heads couldn't generate the TOTP code.\n\nIf this is the first time the system has booted, you should reset the TPM\nand set your own password\n\nIf you just reflashed your BIOS, you'll need to generate a new TOTP secret.\n\nIf you have not just reflashed your BIOS, THIS COULD INDICATE TAMPERING!\n\nHow would you like to proceed?" 30 90 4 \
'g' ' Generate new TOTP/HOTP secret' \
'i' ' Ignore error and continue to default boot menu' \
'p' ' Reset the TPM' \
'x' ' Exit to recovery shell' \
2>/tmp/whiptail || recovery "GUI menu failed"
totp_confirm=$(cat /tmp/whiptail)
fi
fi
fi
if [ "$totp_confirm" = "i" -o -z "$totp_confirm" ]; then
if [ -x /bin/libremkey_hotp_verification ]; then
HOTP=`unseal-hotp`
enable_usb
if ! libremkey_hotp_verification info ; then
whiptail $CONFIG_WARNING_BG_COLOR --clear --title 'WARNING: Please Insert Your Librem Key' --msgbox "Your Librem Key was not detected.\n\nPlease insert your Librem Key" 30 90
fi
# Don't output HOTP codes to screen, so as to make replay attacks harder
libremkey_hotp_verification check $HOTP
case "$?" in
0 )
HOTP="Success"
;;
4 )
HOTP="Invalid code"
MAIN_MENU_BG_COLOR=$CONFIG_ERROR_BG_COLOR
;;
* )
HOTP="Error checking code, Insert Librem Key and retry"
MAIN_MENU_BG_COLOR=$CONFIG_WARNING_BG_COLOR
;;
esac
else
HOTP='N/A'
fi
whiptail $MAIN_MENU_BG_COLOR --clear --title "$CONFIG_BOOT_GUI_MENU_NAME" \
--menu "$date\nTOTP: $TOTP | HOTP: $HOTP" 20 90 10 \
'y' ' Default boot' \
'r' ' Refresh TOTP/HOTP' \
'a' ' Options -->' \
'P' ' Power Off' \
2>/tmp/whiptail || recovery "GUI menu failed"
totp_confirm=$(cat /tmp/whiptail)
fi
if [ "$totp_confirm" = "a" ]; then
whiptail --clear --title "HEADS Options" \
--menu "" 20 90 10 \
'o' ' Boot Options -->' \
't' ' TPM/TOTP/HOTP Options -->' \
's' ' Update checksums and sign all files in /boot' \
'c' ' Change configuration settings -->' \
'f' ' Flash/Update the BIOS -->' \
'G' ' GPG Options -->' \
'x' ' Exit to recovery shell' \
'r' ' <-- Return to main menu' \
2>/tmp/whiptail || recovery "GUI menu failed"
totp_confirm=$(cat /tmp/whiptail)
fi
if [ "$totp_confirm" = "o" ]; then
whiptail --clear --title "Boot Options" \
--menu "Select A Boot Option" 20 90 10 \
'm' ' Show OS boot menu' \
'u' ' USB boot' \
'i' ' Ignore tampering and force a boot (Unsafe!)' \
'r' ' <-- Return to main menu' \
2>/tmp/whiptail || recovery "GUI menu failed"
totp_confirm=$(cat /tmp/whiptail)
fi
if [ "$totp_confirm" = "t" ]; then
whiptail --clear --title "TPM/TOTP/HOTP Options" \
--menu "Select An Option" 20 90 10 \
'g' ' Generate new TOTP/HOTP secret' \
'p' ' Reset the TPM' \
'n' ' TOTP/HOTP does not match after refresh, troubleshoot' \
'r' ' <-- Return to main menu' \
2>/tmp/whiptail || recovery "GUI menu failed"
totp_confirm=$(cat /tmp/whiptail)
fi
if [ "$totp_confirm" = "x" ]; then
recovery "User requested recovery shell"
fi
if [ "$totp_confirm" = "r" ]; then
continue
fi
if [ "$totp_confirm" = "n" ]; then
if (whiptail $CONFIG_WARNING_BG_COLOR --title "TOTP/HOTP code mismatched" \
--yesno "TOTP/HOTP code mismatches could indicate either TPM tampering or clock drift:\n\nTo correct clock drift: 'date -s HH:MM:SS'\nand save it to the RTC: 'hwclock -w'\nthen reboot and try again.\n\nWould you like to exit to a recovery console?" 30 90) then
echo ""
echo "To correct clock drift: 'date -s HH:MM:SS'"
echo "and save it to the RTC: 'hwclock -w'"
echo "then reboot and try again"
echo ""
recovery "TOTP/HOTP mismatch"
else
continue
fi
fi
if [ "$totp_confirm" = "u" ]; then
exec /bin/usb-init
continue
fi
if [ "$totp_confirm" = "g" ]; then
if (whiptail --title 'Generate new TOTP/HOTP secret' \
--yesno "This will erase your old secret and replace it with a new one!\n\nDo you want to proceed?" 16 90) then
update_totp
else
echo "Returning to the main menu"
fi
continue
fi
if [ "$totp_confirm" = "p" ]; then
if (whiptail --title 'Reset the TPM' \
--yesno "This will clear the TPM and TPM password, replace them with new ones!\n\nDo you want to proceed?" 16 90) then
/bin/tpm-reset
Add GUI package update handler w/ checksum update function Part of the Heads workflow involves handling legitimate changes to /boot as part of the package manager. This is a challenging workflow to handle as package managers on many systems work in a completely unattended way (and some even reboot first, apply updates, and then reboot again). We need to be able to detect changes that are potentially caused by a package manager so to do that I've set up a trigger within the OS (currently just for Debian) that runs both before and after package updates. It verifies the signatures in /boot and if they fail before package updates it creates a log file in /boot/kexec_package_trigger_pre.txt. If they fail after package updates run /boot/kexec_package_trigger_post.txt is created. These files contain the following fields: CHANGED_FILES: A list of files in /boot that failed the sha256sum check UPDATE_INITRAMFS_PACKAGE: An (optional) list of packages known to trigger initramfs changes Following those fields is a list of log output from the last package manager run which contains its own formatted fields (I'm pulling from /var/lib/dpkg/info). When a user selects a boot option, gui-init first verifies the checksums just to catch errors before calling kexec-select-boot. If there are any errors it looks for these package logs and if they exist, it displays appropriate warnings. If the files are absent it displays a more generic warning. The user is also given an opportunity to re-sign the /boot hashes.
2018-04-03 22:20:34 +00:00
# now that the TPM is reset, remove invalid TPM counter files
Add GUI package update handler w/ checksum update function Part of the Heads workflow involves handling legitimate changes to /boot as part of the package manager. This is a challenging workflow to handle as package managers on many systems work in a completely unattended way (and some even reboot first, apply updates, and then reboot again). We need to be able to detect changes that are potentially caused by a package manager so to do that I've set up a trigger within the OS (currently just for Debian) that runs both before and after package updates. It verifies the signatures in /boot and if they fail before package updates it creates a log file in /boot/kexec_package_trigger_pre.txt. If they fail after package updates run /boot/kexec_package_trigger_post.txt is created. These files contain the following fields: CHANGED_FILES: A list of files in /boot that failed the sha256sum check UPDATE_INITRAMFS_PACKAGE: An (optional) list of packages known to trigger initramfs changes Following those fields is a list of log output from the last package manager run which contains its own formatted fields (I'm pulling from /var/lib/dpkg/info). When a user selects a boot option, gui-init first verifies the checksums just to catch errors before calling kexec-select-boot. If there are any errors it looks for these package logs and if they exist, it displays appropriate warnings. If the files are absent it displays a more generic warning. The user is also given an opportunity to re-sign the /boot hashes.
2018-04-03 22:20:34 +00:00
mount_boot
mount -o rw,remount /boot
rm -f /boot/kexec_rollback.txt
# create Heads TPM counter before any others
check_tpm_counter /boot/kexec_rollback.txt \
|| die "Unable to find/create tpm counter"
counter="$TPM_COUNTER"
increment_tpm_counter $counter \
|| die "Unable to increment tpm counter"
sha256sum /tmp/counter-$counter > /boot/kexec_rollback.txt \
|| die "Unable to create rollback file"
Add GUI package update handler w/ checksum update function Part of the Heads workflow involves handling legitimate changes to /boot as part of the package manager. This is a challenging workflow to handle as package managers on many systems work in a completely unattended way (and some even reboot first, apply updates, and then reboot again). We need to be able to detect changes that are potentially caused by a package manager so to do that I've set up a trigger within the OS (currently just for Debian) that runs both before and after package updates. It verifies the signatures in /boot and if they fail before package updates it creates a log file in /boot/kexec_package_trigger_pre.txt. If they fail after package updates run /boot/kexec_package_trigger_post.txt is created. These files contain the following fields: CHANGED_FILES: A list of files in /boot that failed the sha256sum check UPDATE_INITRAMFS_PACKAGE: An (optional) list of packages known to trigger initramfs changes Following those fields is a list of log output from the last package manager run which contains its own formatted fields (I'm pulling from /var/lib/dpkg/info). When a user selects a boot option, gui-init first verifies the checksums just to catch errors before calling kexec-select-boot. If there are any errors it looks for these package logs and if they exist, it displays appropriate warnings. If the files are absent it displays a more generic warning. The user is also given an opportunity to re-sign the /boot hashes.
2018-04-03 22:20:34 +00:00
mount -o ro,remount /boot
update_totp
else
echo "Returning to the main menu"
fi
continue
fi
if [ "$totp_confirm" = "m" ]; then
# Try to select a kernel from the menu
mount_boot
Add GUI package update handler w/ checksum update function Part of the Heads workflow involves handling legitimate changes to /boot as part of the package manager. This is a challenging workflow to handle as package managers on many systems work in a completely unattended way (and some even reboot first, apply updates, and then reboot again). We need to be able to detect changes that are potentially caused by a package manager so to do that I've set up a trigger within the OS (currently just for Debian) that runs both before and after package updates. It verifies the signatures in /boot and if they fail before package updates it creates a log file in /boot/kexec_package_trigger_pre.txt. If they fail after package updates run /boot/kexec_package_trigger_post.txt is created. These files contain the following fields: CHANGED_FILES: A list of files in /boot that failed the sha256sum check UPDATE_INITRAMFS_PACKAGE: An (optional) list of packages known to trigger initramfs changes Following those fields is a list of log output from the last package manager run which contains its own formatted fields (I'm pulling from /var/lib/dpkg/info). When a user selects a boot option, gui-init first verifies the checksums just to catch errors before calling kexec-select-boot. If there are any errors it looks for these package logs and if they exist, it displays appropriate warnings. If the files are absent it displays a more generic warning. The user is also given an opportunity to re-sign the /boot hashes.
2018-04-03 22:20:34 +00:00
verify_global_hashes
if [ $? -ne 0 ]; then
continue
fi
kexec-select-boot -m -b /boot -c "grub.cfg" -g
continue
fi
if [ "$totp_confirm" = "i" ]; then
# Run the menu selection in "force" mode, bypassing hash checks
if (whiptail $CONFIG_WARNING_BG_COLOR --title 'Unsafe Forced Boot Selected!' \
--yesno "WARNING: You have chosen to skip all tamper checks and boot anyway.\n\nThis is an unsafe option!\n\nDo you want to proceed?" 16 90) then
mount_boot
kexec-select-boot -m -b /boot -c "grub.cfg" -g -f
else
echo "Returning to the main menu"
fi
continue
fi
if [ "$totp_confirm" = "s" ]; then
prompt_update_checksums
continue
fi
if [ "$totp_confirm" = "c" ]; then
config-gui.sh
continue
fi
if [ "$totp_confirm" = "f" ]; then
flash-gui.sh
continue
fi
if [ "$totp_confirm" = "G" ]; then
gpg-gui.sh
continue
fi
if [ "$totp_confirm" = "P" ]; then
poweroff
fi
if [ "$totp_confirm" = "y" -o -n "$totp_confirm" ]; then
# Try to boot the default
mount_boot
Add GUI package update handler w/ checksum update function Part of the Heads workflow involves handling legitimate changes to /boot as part of the package manager. This is a challenging workflow to handle as package managers on many systems work in a completely unattended way (and some even reboot first, apply updates, and then reboot again). We need to be able to detect changes that are potentially caused by a package manager so to do that I've set up a trigger within the OS (currently just for Debian) that runs both before and after package updates. It verifies the signatures in /boot and if they fail before package updates it creates a log file in /boot/kexec_package_trigger_pre.txt. If they fail after package updates run /boot/kexec_package_trigger_post.txt is created. These files contain the following fields: CHANGED_FILES: A list of files in /boot that failed the sha256sum check UPDATE_INITRAMFS_PACKAGE: An (optional) list of packages known to trigger initramfs changes Following those fields is a list of log output from the last package manager run which contains its own formatted fields (I'm pulling from /var/lib/dpkg/info). When a user selects a boot option, gui-init first verifies the checksums just to catch errors before calling kexec-select-boot. If there are any errors it looks for these package logs and if they exist, it displays appropriate warnings. If the files are absent it displays a more generic warning. The user is also given an opportunity to re-sign the /boot hashes.
2018-04-03 22:20:34 +00:00
verify_global_hashes
if [ $? -ne 0 ]; then
continue
fi
DEFAULT_FILE=`find /boot/kexec_default.*.txt 2>/dev/null | head -1`
if [ -r "$DEFAULT_FILE" ]; then
kexec-select-boot -b /boot -c "grub.cfg" -g \
|| recovery "Failed default boot"
else
if (whiptail --title 'No Default Boot Option Configured' \
--yesno "There is no default boot option configured yet.\nWould you like to load a menu of boot options?\nOtherwise you will return to the main menu." 16 90) then
kexec-select-boot -m -b /boot -c "grub.cfg" -g
else
echo "Returning to the main menu"
fi
continue
fi
fi
done
recovery "Something failed during boot"