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.
Or if we are enabling backports, then simply omit setting this apt config in VBox builds to begin with while designating the stable kernel during the build process?
Enabling backports is inappropriate for a distribution.
Enabling backports alone does nothing. Still required APT pinning, which again is inappropriate for a distribution.
References:
If not using virtualizer specific kernel versions: Would have to download the package from Debian backports and upload to Whonix stable.
If using virtualizer specific kernel versions: Would require some packaging hack. Perhaps require to recompile the kernel.
If recompile on developer machine - perhaps for all architectures.
I don’t like the idea of virtualizer specific kernel versions. That’s adding a lot complexity. Hard to develop / test since involving different tests on different virtualizers.
It would also only be effective for a platform that I don’t maintain, KVM.
(Qubes is not yetQubes VM kernel by default.)