kernel recompilation for better hardening

Looks really good already. I have to read more carefully, but I guess it will only be nitpicks from my side. You could also post the draft here: https://www.whonix.org/wiki/Fixing_the_Desktop_Linux_Security_Model

Could you please convert

security vulnerabilities [1]


security vulnerabilities

Unless there is a reason not to do this?

or both

security vulnerabilities [1]?

I guess both ([number] style + forum links) would be good to - because then this can be re-posted on mailing lists.

tirdad is a kernel module that aims to prevent TCP Initial Sequence Number (ISN) based information leaks by randomizing the TCP ISNs [6]. This is more of anonymity feature than a security feature.

Did you see this security argument here?


Could you please mention maybe SAK, login spoofing, the mostly sudo security theater and how multiple boot modes for better security: persistent user | live user | persistent admin | persistent superadmin | persistent recovery mode would fix that?

Worth mentioning all Upcoming Security Enhancements?

Untrusted Root User

deactivate malware after reboot from non-root compromise

Mount Options Hardening

Disable SUID Binaries

Whonix is a security, privacy and anonymity focused Linux distribution. Recently, we’ve been focusing a lot on important security hardening measures and fixing architectural security issues within the desktop Linux security model.

Could you please make more clear that any desktop Linux distribution is affected?

1 Like

Most are part of security-misc so there’s not much reason to mention them separately. I extended the security misc section a bit and added your suggestions https://paste.debian.net/hidden/46d2b42e/

1 Like

Btw the sandbox-app-launcher link is https://github.com/Whonix/sandbox-app-launcher which doesn’t exist. Should I change it to https://github.com/madaidan/sandbox-app-launcher or will you fork it?

1 Like

madaidan via Whonix Forum:

Btw the sandbox-app-launcher link is https://github.com/Whonix/sandbox-app-launcher which doesn’t exist. Should I change it to https://github.com/madaidan/sandbox-app-launcher or will you fork it?

Forked just now.
(Will reply to other things soonish.)

1 Like

Made some minor edits.


Could you (for authorship recognition) post this please (Whonix development forum)? I’ll then move to Whonix News Forums and repost on usual social media.

1 Like
1 Like

Is https://github.com/Whonix/hardened-kernel/pull/51 going to be merged?

1 Like

2 posts were merged into an existing topic: Fixing the Desktop Linux Security Model

That and https://phabricator.whonix.org/T955 is really over my head.

Could you please work on hardened-kernel outreach?

1 Like

I found this presentation from Kees Cook on Clang vs GCC security.

Some of these are being worked on though like Clang stack probing.


Also, on Clang stack variable auto-initialization:

1 Like

CONFIG_DRM_LEGACY: Really old drivers from the 90s, with unfixable by design security holes. Unfortunately userspace for one modern driver (drm/nouveau) has used until just a few years ago by accident (we didn’t delete all the old legacy driver setup code), so can’t remove it all completely yet from kernel sources.

CONFIG_FB: Old display subsystem from the 90s, essentially unmaintained for over 10 years, would need serious effort to get up to speed with modern security best practices. This even includes the minimal fbdev emulation support built on top of drm gpu drivers, since the issues are in core fbdev code.

CONFIG_VT: Maybe the most disputed of all, but a lot of the console drivers this exposes to userspace are also from the 90s, and without CONFIG_FB this isn’t really useful even for a desktop. A hardened distro definitely wants to make sure this is not set at all.

Disabling CONFIG_FB and CONFIG_VT might break stuff (not sure) but we definitely don’t need CONFIG_DRM_LEGACY.

I would send a pull request to disable it but it’d likely cause a merge conflict since https://github.com/Whonix/hardened-kernel/pull/51 isn’t merged yet.

The linux-hardened TCP simultaneous connect pull request was also merged.

1 Like
1 Like

CLIP OS recently disabled CONFIG_VHOST.


The vhost protocol offloads the virtio dataplane implementation to the kernel. This reduces isolation of virtual machines, by getting rid of the existing protocol break and increasing the host kernel attack surface. Note that this option cannot actually be manually toggled as it is automatically selected by other options such as CONFIG_VHOST_NET . As a consequence, blacklisting it prevents all vhost features from being enabled.

Does anything we use require this? //cc @HulaHoop

They also disable CONFIG_DRM_LEGACY.

https://review.clip-os.org/plugins/gitiles/clipos/src_platform_config-linux-hardware/+/c1fcf37cbe9738a7b286770afae6fd3bfd0e06cc^!/#F1 (this hasn’t been merged yet)

1 Like

Nope. Always went for userspace virtio devices for better isolation because bugs in vhost would be fatal.

1 Like


This isn’t in our kernel version though so we don’t need to worry (benefits of LTS).


Could you please work on hardened-kernel outreach? @madaidan

1 Like

I think it’s too early for that and I don’t think many listed there would be interested in it. MirageOS doesn’t even use Linux. It’s a framework for building unikernels.

Unrelated to outreach but can be useful for improving build speed:


The idea isn’t that distributions build and upload the kernel to their
distribution very soon. That may or may not be realistic indeed.

The idea is to get attention on the project. Have other competent people
review and contribute.

Because at the moment it’s stalled. This got much more complicated than
I anticipated and I really can’t review the kernel config.

1 Like

I highly doubt any standard distro would be interested in this. The only reason Arch has a package is because anthraxx/Daniel Micay are Arch maintainers/Trusted Users. Tails and Qubes are the only ones I see that might be interested. Gentoo (Hardened) might be interested in linux-hardened but not hardened-kernel since they always create their own config.

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]