Possibly.
1 Like
1 Like
Contacted Colin Childs @Phou through twitter DM.
hello
since you’ve previously worked on coldkernel…
any chance to get you interested in GitHub - Kicksecure/hardened-kernel: Hardened kernel configuration optimized for virtual machines. - https://www.kicksecure.com/wiki/Hardened-kernel ?
not grsecurity but using GitHub - anthraxx/linux-hardened: Minimal supplement to upstream Kernel Self Protection Project changes. Features already provided by SELinux + Yama and archs other than multiarch arm64 / x86_64 aren't in scope. Only tags have stable history. Shared IRC channel with KSPP: irc.libera.chat #linux-hardening and a hardened kernel config
hardened-kernel
^ Patrick
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 GitHub - anthraxx/linux-hardened: Minimal supplement to upstream Kernel Self Protection Project changes. Features already provided by SELinux + Yama and archs other than multiarch arm64 / x86_64 aren't in scope. Only tags have stable history. Shared IRC channel with KSPP: irc.libera.chat #linux-hardening let alone hardened-kernel-config / GitHub - Kicksecure/hardened-kernel: Hardened kernel configuration optimized for virtual machines. - https://www.kicksecure.com/wiki/Hardened-kernel.
2 Likes
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”.
1 Like
Yes, very much so!
1 Like
How is Debian paste error?
1 Like
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]
to
Unless there is a reason not to do this?
or both
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 secureadmin | 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 Debian paste error
1 Like
Btw the sandbox-app-launcher link is GitHub - Kicksecure/sandbox-app-launcher: An app launcher to start apps in a restrictive sandbox https://www.kicksecure.com/wiki/sandbox-app-launcher which doesn’t exist. Should I change it to GitHub - madaidan/sandbox-app-launcher: An app launcher to start apps in a restrictive sandbox or will you fork it?
1 Like
madaidan via Whonix Forum:
Btw the sandbox-app-launcher link is GitHub - Kicksecure/sandbox-app-launcher: An app launcher to start apps in a restrictive sandbox https://www.kicksecure.com/wiki/sandbox-app-launcher which doesn’t exist. Should I change it to GitHub - madaidan/sandbox-app-launcher: An app launcher to start apps in a restrictive sandbox or will you fork it?
Forked just now.
(Will reply to other things soonish.)
1 Like
Made some minor edits.
https://paste.debian.net/hidden/a23557b4/
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 Disable unneeded drivers by madaidan · Pull Request #51 · Kicksecure/hardened-kernel · GitHub going to be merged?
1 Like
2 posts were merged into an existing topic: Fixing the Desktop Linux Security Model
That and ⚓ T955 review hardened kernel config 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 Disable unneeded drivers by madaidan · Pull Request #51 · Kicksecure/hardened-kernel · GitHub 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.
https://docs.clip-os.org/clipos/kernel.html#virtualization
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.
2 Likes