I know the question of using the stable vs testing branch on a distro level, is settled for Whonix but I feel there are compelling arguments to raise it for the kernel package specifically as the most critical part for system safety and also because it’s self contained. Also in light of the spectre debacle and what fixes are not backported to older LTS kernels supported in stable are worth a new look.
Here is what Greg Kroah has to say as far as kernel security and the recommended versions one should run.
The number of security fixes that get backported are not as great as with the latest LTS release, because the traditional model of the devices that use these older LTS kernels is a much more reduced user model. These kernels are not to be used in any type of “general computing” model where you have untrusted users or virtual machines, as the ability to do some of the recent Spectre-type fixes for older releases is greatly reduced, if present at all in some branches.
So, here’s a short list of different types of devices, and what I would recommend for their kernels:
Laptop / Desktop: Latest stable release
Server: Latest stable release or latest LTS release
Embedded device: Latest LTS release or older LTS release if the security model used is very strong and tight.
The kernels in sid/testing/backports are usually not in sync with the ones listed as LTS on kernel.org but I think they provide a good compromise between recency and stability.
https://www.kernel.org/category/releases.html
My recommendation based on what he said is to have Whonix install the latest cloud version in backports to have the latest fixes and a lesser number of security bugs.
It seems Qubes is basing off of the same version as in backports (4.17 as of writing).
Pros:
*Offloading maintenance works and benefitting from safety measures taken by security conscious devs.
Cons:
*Packaged as rpm. Not possible to use without hacks like running it through alien or explicitly changin the build process to output debs.
*We lose out on reproducible builds when they come online upstream when Buster comes around.
*We run much more code [0] than we need in a virtual environment compared to using [1]. They must do this however for maximum hardware compatibility but this isn’t in our scope for virtualized Whonix builds which are better off using the barebones kernel configs to cut down on attack surface.
(I didn’t mean to suggest for Non-Qubes-Whonix to use the very same kernel package (rpm) as Qubes. While I don’t want to preemptively exclude it, I didn’t consider to research that. I guess alien will never be good enough and could go horribly wrong for a package as important as the linux package. Horribly wrong: missing maintainer scripts, kernel post install scripts, other incompatibilities Fedora vs Debian, breaking boot)
Pros:
VM startup much quicker. 90% of boot time avoided.
Cons:
Mouse cursor needs to be released from guest hotkey combination.
Shared folders on KVM broken because the module is not compiled into the kernel.
While it automatically fetches the VBox guest additions package there is an error message during the install that indicates the DKMS build is broken “Error!Bad return status for module build on kernel” I attached the log for those interested but it seems to be code problem with that package rather than a build dependency failure. Can’t upload log because forum forbids it.
So close but no cigar. Next up is regular backports which we can lockdown module loading for instead, at some point to reduce attack surface.
Its possible to compile a standalone module against the header for use even after the fact AFAIK.
Nope. Those are the ones from backports that are fetched automatically with this kernel is seems.
According to lockdown’s README yes you can. It’s not a strong guarantee as not having the code in the first place as someone with root can disable it, but it’s better than nothing.
However it only takes effect after a reboot which would be detectable by a user. So if one restores after a session the window of compromise is non-existent.
Configure by editing /etc/default/lockdown to enable/disable features
and adjust settings.
Everything works as expected with full stable-backports. No errors burped out about VBox Guest Additions (the latest in backports which is automatically fetched).
Debian has a cloud kernel initiative where they now have linux images optimized for performance on hypervisors and also contain the bare minimum modules needed to boot on major hypervisor platforms which is good for security. Though with the upcoming lockdown feature the extra modules can still be made off limits for attackers if not used.
This kernel version is available in buster and stretch backports which means we probably can’t use it for our purposes but good to consider for later.
linux-image-cloud-amd64 does not boot in VirtualBox. Also not when removing hardening boot parameters by security-misc package. Also not in recovery mode. Just a black screen.
Not sure if I’ve already reported this before but when I tried it, it was very minimalistic lacking even modules for shared folders to work. I think they are designed to work with KVM configurations so its almost certain VBox and Xen won’t be able to run it.
One worry is that VirtualBox guest additions might break and be unfixeable for a while. While at the same time, downgrade to a kernel compatible with VirtualBox guest additions isn’t possible through in-place upgrades (apt dist-upgrade) for existing users.
I assume the whole point of backporting though is to guarantee this type of bad breakage doesn’t happen? Including stuff from backports gets us some form of upstream support if it doesn’t work
Build flag is doable in theory. But messy due to below…
Repository upgrades: not easy. Not possible without having separate apt repositories or some kind of packaging hack (Conflicts:?) which doesn’t install the backport kernel in VirtualBox.