heads/initrd/bin/gui-init

273 lines
10 KiB
Plaintext
Raw Normal View History

#!/bin/sh
# Boot from a local disk installation
CONFIG_BOOT_GUI_MENU_NAME='Heads Boot Menu'
. /etc/functions
. /etc/config
mount_boot()
{
# Mount local disk if it is not already mounted
if ! grep -q /boot /proc/mounts ; then
mount -o ro /boot \
|| recovery "Unable to mount /boot"
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
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
update_checksums
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
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
update_checksums
fi
return 1
fi
}
update_checksums()
{
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
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
cd /boot
find ./ -type f ! -name '*kexec*' | xargs sha256sum > /boot/kexec_hashes.txt
DEFAULT_FILES=$(cat /boot/kexec_default_hashes.txt | cut -f3 -d ' ')
echo $DEFAULT_FILES | xargs sha256sum > /boot/kexec_default_hashes.txt
# Remove any package trigger log files
# We don't need them after the user decides to sign
rm -f /boot/kexec_package_trigger*
# sign and auto-roll config counter
extparam=
if [ "$CONFIG_TPM" = "y" ]; then
extparam=-u
fi
kexec-sign-config -p /boot $extparam \
|| die "Failed to sign default config"
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
# switch back to ro mode
mount -o ro,remount /boot
else
echo "Returning to the main menu"
fi
}
last_half=X
while true; do
MAIN_MENU_OPTIONS=""
unset totp_confirm
# 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 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\nIf this is the first time the system has booted, you should reset the TPM\nand set your own password\n\nHow would you like to proceed?" 30 90 4 \
'g' ' Generate new TOTP 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
if [ "$totp_confirm" = "i" -o -z "$totp_confirm" ]; then
whiptail --clear --title "$CONFIG_BOOT_GUI_MENU_NAME" \
--menu "$date\nTOTP code: $TOTP" 20 90 10 \
'y' ' Default boot' \
'r' ' TOTP does not match, refresh code' \
'n' ' TOTP does not match after refresh, troubleshoot' \
'o' ' Other Boot Options -->' \
'a' ' Advanced Settings -->' \
'x' ' Exit to recovery shell' \
2>/tmp/whiptail || recovery "GUI menu failed"
totp_confirm=$(cat /tmp/whiptail)
fi
if [ "$totp_confirm" = "o" ]; then
whiptail --clear --title "Other 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" = "a" ]; then
whiptail --clear --title "Advanced Settings" \
--menu "Configure Advanced Settings" 20 90 10 \
'g' ' Generate new TOTP secret' \
'p' ' Reset the TPM' \
's' ' Update checksums and sign all files in /boot' \
'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 code mismatched" \
--yesno "TOTP 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 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 secret' \
--yesno "This will erase your old secret and replace it with a new one!\n\nDo you want to proceed?" 16 90) then
echo "Scan the QR code to add the new TOTP secret"
/bin/seal-totp
echo "Once you have scanned the QR code, hit Enter to reboot"
read
/bin/reboot
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, erase the old TPM password and replace it with a new one!\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 kexec_rollback.txt file
mount_boot
mount -o rw,remount /boot
rm -f /boot/kexec_rollback.txt
mount -o ro,remount /boot
echo "Scan the QR code to add the new TOTP secret"
/bin/seal-totp
echo "Once you have scanned the QR code, hit Enter to reboot"
read
/bin/reboot
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
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
update_checksums
continue
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"