[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

kernel recompilation for better hardening

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.

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 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.

https://www.phoronix.com/scan.php?page=news_item&px=LLVM-Stack-Clash-Protection-P

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.

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
1 Like

https://review.clip-os.org/c/clipos/src_platform_config-linux-hardware/+/35685/

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

2 Likes

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:

https://grsecurity.net/faster_multicore_linux_kernel_build_testing

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

Interested distributions would be jackpot but my hope is lower and hopefully more realistic: anyone capable of contributing. And I guess that chance is realistic. There used to be a lot enthusiasm and auxiliary protects for grsecurity (download, compile scripts such as coldkernel, packages and whatnot). I would be really surprised if zero people could get excited about this project now that there is no longer any grsecurity free or other somehow popular (people having heard about it) alternative.

1 Like

grsecurity isn’t really the same. It was well known for providing a large set of security features. linux-hardened doesn’t come close.

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