That is a good idea.
A nested grub boot menu is not possible due to the /etc/grub.d / update-grub framework limitations.
A systemd unit file that runs very early at boot could do. Systemd unit files are capable of accepting user terminal input such. There could be an option YES (continue boot) | NO (reboot) and a timeout which continues booting after XX seconds. Systemd unit files are as far as I know also capable of interrupting the boot process until some systemd unit has finished (timeout).
That may be too late and the malware could’ve already exploited superroot.
It would be best to have it pre-boot. Maybe an ncurses menu in the initramfs? Is that even possible?
Possibly? Pre boot FDE password entry is inside initramfs or outside?
Outside. The bootloader decrypts everything before starting the initramfs.
What does this have to do with it?
Pre boot password entry is very early. Either in /boot or initramfs. It’s an example of interactive console. Source code for inspiration for superroot warning.
Grub can encrypt /boot somehow but it’s not a feature that any distribution installers use that I know. Debian installer doesn’t use it. initramfs, kernel image, whole /boot is unencrypted.
It seems like decryption actually happens in the initramfs. I initially thought it happened in grub due to the need for a cryptdevice boot parameter but looking into it more, it looks like the cryptroot initramfs hook does it.
That hook seems to use the cryptsetup_message function in /lib/cryptsetup/functions for messages and the source code of that function is:
cryptsetup_message() {
local IFS=' '
if [ "${0#/scripts/}" != "$0" ] && [ -x /bin/plymouth ] && plymouth --ping; then
plymouth message --text="cryptsetup: $*"
elif [ ${#*} -lt 70 ]; then
echo "cryptsetup: $*" >&2
else
# use busybox's fold(1) and sed(1) at initramfs stage
echo "cryptsetup: $*" | fold -s | sed '1! s/^/ /' >&2
fi
return 0
}
Also, files such as /lib/cryptsetup/functions need to be protected by dangerous-files too. Otherwise an attacker can just edit something like cryptsetup_message() to run rm /etc/apparmor.d/init-systemd to bypass the policy.
Edit:
/lib/cryptsetup/functions is actually already read-only due to apparmor-profile-everything making all libraries/binaries read-only. We should still look around for other things like this that are not protected in the policy though.
There doesn’t seem to be anything that isn’t protected. All files sourced can be checked with
grep -or '\. /[^"]*' /{,usr/share,etc}/initramfs-tools/ | sed -e 's/.*://g' | awk '!x[$0]++'
Directories like /scripts/ are created in the initramfs from /**/initramfs-tools/ AFAIK.
We should probably mount the securityfs with nosuid, nodev and noexec but this isn’t too important as barely any of /sys/kernel/security is allowed in the policy anyway.
I think we will have to use plymouth for the early boot prompt but I have no idea how to use that.
I don’t like plymouth much. It seems only needed for fancy graphics during boot. I used to have some plymouth in past and hence used all my systems without it. It however looks entirely optional… The code you quoted:
Has fallbacks if plymouth isn’t installed. Pre boot FDE password entry is fully functional without plymouth. A warning message against superroot is probably easier than a password prompt.
Quote GNU GRUB Manual 2.12
grub-mkconfigdoes have some limitations. While adding extra custom menu entries to the end of the list can be done by editing /etc/grub.d/40_custom or creating /boot/grub/custom.cfg, changing the order of menu entries or changing their titles may require making complex changes to shell scripts stored in /etc/grub.d/. This may be improved in the future. In the meantime, those who feel that it would be easier to write grub.cfg directly are encouraged to do so (see Booting, and Shell-like scripting), and to disable any system provided by their distribution to automatically rungrub-mkconfig.
However, /boot/grub/grub.cfg menu entries are nicely marked by a top and bottom comment.
### BEGIN /etc/grub.d/filename ###
### END /etc/grub.d/filename ###
That looks very parse. Perhaps the grub submenu which shows the warning could be warped around it.
Its fallbacks are just echo. Not any interactive prompts.
I’ve tried using dialog in the initramfs but that didn’t work.
Also, I shortened the boot parameters Shorter options · madaidan/apparmor-profile-everything@e7e1cf1 · GitHub
Could use bash built-in read?
(Similar to read password .)
(In combination with timeout.)
That’s not as user friendly as a GUI prompt but could work.
I tried adding a prompt using read to /etc/initramfs-tools/scripts/init-bottom/apparmor-profile-everything. I didn’t see any prompts during boot but the boot did hang. Likely because it was waiting for me to answer the prompt.
I don’t know how to make the prompt show up in the console.
read doesn’t show any prompt. Still needs to use echo before. Might be able to use colors. (See colors in Whonix source code.)
Can’t we copy/paste from pre boot fde password entry prompt code?
You can use the -p flag:
read -r -p "text" prompt
I don’t know where that code is. I’ve tried looking but can’t find it.
(edit: off topic, nevermind)
madaidan via Whonix Forum:
We should probably mount the securityfs with nosuid, nodev and noexec but this isn’t too important as barely any of /sys/kernel/security is allowed in the policy anyway.
Done in git master.
https://github.com/Whonix/security-misc/blob/master/usr/lib/security-misc/remount-secure#L71-L77
securityfs is mounted with nosuid, nodev and noexec by default but apparmor-profile-everything would prevent that as we are mounting it ourselves in the initramfs.