[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [Priority Support]

Kernel versions and security


#1

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.

http://kroah.com/log/blog/2018/08/24/what-stable-kernel-should-i-use/

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.


Long Wiki Edits Thread
#2

Big difference in kernel versions.

Stretch has 4.9 something, while backports has 4.17.17 at present. Totally agree with all this, and we should make a firm recommendation in the wiki.


#3

Wondering if/how this could be done in Whonix by default. Any

  • Debian (preferred)
  • (or third party [kernel.org?] deb?)

repository we could download kernel and headers from and then upload to Whonix repository?

What about Qubes VM kernel? How good is that one? Could anyone please submit feature request against Qubes?

That would help to make this argument better vetted (as far as stability, practicality, maintainability)!


#4

+1

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.

[0] https://github.com/QubesOS/qubes-linux-kernel/blob/master/config-base
[1] https://packages.debian.org/stretch-backports/linux-image-cloud-amd64


#5

https://packages.debian.org/stretch-backports/linux-image-cloud-amd64 - can consider. Could maybe download from stretch-backports and add to Whonix stretch repository. Could you manually test please if it works?

Also need https://packages.debian.org/stretch-backports/linux-headers-cloud-amd64.

Does https://packages.debian.org/stretch-backports/linux-image-cloud-amd64 break https://packages.debian.org/stretch-backports/virtualbox-guest-x11? Could you manually test please if it works?


(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)


Whonix for arm64 / Raspberry Pi ( RPi )
#6

Observations for backports cloud image:

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.


#7

Bug reports worth it or out of scope of that package?

Would that be fixed on recompilation of… Oh well, there is no guest additions to recompile so no joy?

https://packages.debian.org/stretch-backports/linux-headers-cloud-amd64 certainly required for this.

Do guest additions from backports work?

Can we pick modules by an opt-in basis?


#8

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.


#9

Everything works as expected with full stable-backports. No errors burped out about VBox Guest Additions (the latest in backports which is automatically fetched).


#10

Do you think it’s a maintainable solution to also grab lockdown from testing and upload it in Whonix repos?

I tested installing it and it needs no deps not present in stable.

The default setting locks in any detected loaded modules within 10 seconds of booting which should cover any built-in hardware.

https://packages.debian.org/buster/lockdown