Sure! Where should it be?
Yes. It’s easy to add a livecd to a VM.
That will require you to manually decrypt and mount it but I don’t have much experience with that.
How would the kernel parameter be implemented? A systemd service that greps /proc/cmdline?
What exactly do we look for though?
Those are more pragmatic options IMO.
@Patrick Host hardening guide perhaps?
Recovery - Kicksecure for now (we could still move elsewhere later if needed).
A systemd service isn’t needed. https://github.com/Whonix/security-misc/blob/master/usr/lib/security-misc/panic-on-oops (since running as root anyhow) could directly parse /proc/cmdline.
whonix-xfce-desktop-config /usr/share/livecheck/livecheck.sh is using:
if grep -qs "boot=live" /proc/cmdline; then
Which boot options should we look for?
nooops why not…kernel.panic_on_oops=1 such as recovery, single (these are from Ubuntu, do these work with Debian too?) Know any Debian boot options usually used for recovery?The kernel oops message. By parsing dmesg line by line I would hope we can find a common pattern which is easy to parse.
[ 5660.841924] BUG: soft lockup - CPU#0 stuck for 61s! [egrep:10518]
Internal error: Oops:
We need to search for logs that mention oopses and then just grep/match/or so them.
nooops doesn’t sound right. Something like no_panic_on_oops would be good.
Tails has a troubleshooting mode with some kernel parameters that are usually used in debugging.
We could create our own troubleshooting mode with some of those kernel parameters and disable the panic on oops.
Btw grub boot menu allows adding boot parameters “on the fly” during grub boot menu.
See grub2 - How do I add a kernel boot parameter? - Ask Ubuntu
To temporarily add a boot parameter to a kernel:
It could even be both. Simple to match for it. no_panic_on_oops is kinda harder to type (as per above during grub boot menu stage).
Sounds good.
I’ve made a draft for the chrooting.
What might also be cool (but also less secure, risking host compromise when VM is compromised) is mounting the disk image on the host.
Why is chrooting even required? For recovering files, just mount the disk and copy?
For changing config files, also no chroot required.
Chroot should only be required in limited cases such as uninstallation of a package.
Related (on mounting disk images):
File Transfer - Whonix (but disk image mounting must be radically simplified, shouldn’t depend on re-using Whonix source code, too difficult)
It can allow you to fix certain things without having to boot directly into the machine. e.g. if you’ve enabled kernel.panic_on_oops=1 and get kernel panics on boot, you can chroot to fix it.
Not required. KVM does not depentd on “guest additions” to share files. Rather the shared folder 9p protocol is a module in the guest kernel that is compatible with a filesystem device added on the host.
For completion the guestfs tool is the main and safe(ish) way to mount qcow2
http://ask.xmodulo.com/mount-qcow2-disk-image-linux.html
I say safeish because while it does implement Apparmor protections to the processes that interact with the guest file system it is not as theoretically safe as shared folder used directly.
I’ve just noticed this in the kernel docs:
Always panic on oopses. Default is to just kill the process, but there is a small probability of deadlocking the machine.
linux-hardened also sets this option.
https://github.com/anthraxx/linux-hardened/blob/5.2/lib/Kconfig.debug#L998
dmesg can filter out the logs based on priority. Running dmesg -l emerg gives you emergency logs. This will make it much easier to check for kernel oopses.
Grsecurity has a smarter equivalent to this.
Sounds a ton smarter indeed.