Contacted Colin Childs @Phou through twitter DM.
since you’ve previously worked on coldkernel…
any chance to get you interested in https://github.com/Whonix/hardened-kernel ?
not grsecurity but using https://github.com/anthraxx/linux-hardened and a hardened kernel config
What this project needs most is outreach. Getting developers interested that previously worked on packaging grsecurity, grsecurity installers, etc. Most simply gave up after grsecurity was gone. Very few know about the existence of https://github.com/anthraxx/linux-hardened let alone hardened-kernel-config / https://github.com/Whonix/hardened-kernel.
I think it might be a good idea to create a large post detailing all of our recent security hardening work including security-misc, apparmor-profile-everything, hardened-kernel, sandbox-app-launcher, hardened_malloc, LKRG and tirdad and the issues they aim to fix, similar to The Problem with Security Guides and How We Can Fix It. It could have the potential to attract a lot of new people as it’s not just kernel stuff but also MAC, sandboxing, memory allocators etc.
I could write something up if you’re interested. A good title may be something like “Fixing the Desktop Linux Security Model”.
Yes, very much so!
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 
Unless there is a reason not to do this?
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 . 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?
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?
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/
madaidan via Whonix Forum:
Forked just now.
(Will reply to other things soonish.)
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.
Is https://github.com/Whonix/hardened-kernel/pull/51 going to be merged?
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?
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:
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.
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.
Nope. Always went for userspace virtio devices for better isolation because bugs in vhost would be fatal.