Kernel versions and security / Debian backports

[Patrick]

@HulaHoop

Also another thing I just thought of: enhanced security configs in security-misc may use features not available in the older stable kernel?

Not sure. Probably just ignored.

@HulaHoop

Is there a way we can test how things go with VBox before deploying this change?

Yes. Try out.
That’s why all changes go through developers → testers → stable-proposed-updates → stable repository.

The problem here is, we cannot predict the future. If backport kernels will break VirtualBox guest additions.

@HulaHoop

What do users lose without functional guest additions installed?

Major things coming to mind:

• Fixed screen resolution (too big, too small, scrolling, not using full window space, black border).
• No shared folders.
• No copy/paste from inside/outside VM.
• Trapping of keyboard/mice inside VM until VirtualBox host key is pressed.
• Performance?

more details here perhaps:
https://www.virtualbox.org/manual/ch04.html

[HulaHoop]

@Patrick

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

The lesser evil. A packaging hack is the path of least resistance IMO.

[HulaHoop]

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?

[Patrick]

Enabling backports is inappropriate for a distribution.
Enabling backports alone does nothing. Still required APT pinning, which again is inappropriate for a distribution.
References:

Dev/APT Pinning

• 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.
    • (related: issues to compiling for all architectures as per this very post Whonix for arm64 / Raspberry Pi ( RPi ) - duplicate forum topic - #143)
  • Or recompile on user’s machine, which is also unsolved. See this very post kernel recompilation for better hardening - #77 by Patrick starting from However, there is one blocker.

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 yet Qubes VM kernel by default.)

[Patrick]

Debian bug linux-image-amd64 vs linux-headers-amd64 Debian buster-backports version mismatch bpo.2 vs bpo.3 shows that just enabling backports repository might lead to issues. In this example, breaking all kernel modules due to kernel image vs kernel headers version mismatch from backports packages.debian.org.

[HulaHoop]

OK. That’s a good citation for the wiki on why we don’t enable backports.

[Patrick]

added here:
Dev/APT Pinning - Kicksecure

[Patrick]

Are all Linux vendor kernels insecure? A new study says yes, but there's a fix