https://github.com/anthraxx/linux-hardened/issues/10#issuecomment-521595245
IMO packaging is some downstream job. Here are only pure kernel sources which are distro agnostic. Anyway adding one more patch to debian kernels should be trivial to do (assuming you are familiar with debian kernels packaging already).
- 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 has git branch
5.2and git tag5.2.6.a(also5.2.8.a) - Debian kernel team / linux · GitLab has git tag
5.2.6-1(Files · debian/5.2.6-1 · Debian kernel team / linux · GitLab)
In theory git checkout linux-hardened 5.2.6.a as well as debian kernel-team/linux git checkout 5.2.6-1, copy over the Debian folder from Debian linux kernel to linux-hardened and compile.
Could you try that please?
Ben Hutchings:
On Thu, 2019-08-15 at 12:00 +0000, Patrick Schleizer wrote:
Package: linux
Severity: wishlist
X-Debbugs-CC: whonix-devel@whonix.orgDear maintainer,
Could you please consider review and merge of linux-hardened patches
(free, Libre alternative to grsecurity).Alternatively perhaps as a separate package.
RFP: linux-hardened - hardened Linux kernel
Any large patch set that is not upstream would need to be applied as an
optional “featureset”. (The “lockdown” patch set has been an exception
to this because Secure Boot was an obstacle to installing Debian and we
needed to support in the default kernel.) The requirements for a
featureset are roughly:
- Its developers should be actively working to get those patches
upstream.- There must be at least someone within the kernel team who takes
responsibility for maintaining it.- It should have regular verifiable releases. (Also, if it isn’t
updated for a new upstream version, we won’t wait for it but will
disable building it temporarily.)I would much prefer to see hardening changes that we can apply by
default, protecting the majority of Debian systems. We do apply some
small patches so that we can enable building high-risk features but
have them disabled at run-time by default. Even though these aren’t
upstream, they rarely require work to apply to new upstream versions.
I would certainly be open to changes of this sort.Ben.
Probably worth to take a look at:
https://www.kernel.org/doc/html/v4.14/admin-guide/LSM/LoadPin.html
LoadPin is a Linux Security Module that ensures all kernel-loaded files (modules, firmware, etc) all originate from the same filesystem, with the expectation that such a filesystem is backed by a read-only device such as dm-verity or CDROM. This allows systems that have a verified and/or unchangeable filesystem to enforce module and firmware loading restrictions without needing to sign the files individually.
I find IMA in particular interesting:
https://en.opensuse.org/SDB:Ima_evm
This document describes the IMA and EVM technologies from the Linux integrity subsystem, and how they can be utilized on SUSE Linux distributions.
Basically IMA and EVM provide the following functionality:
measurement (hashing) of file content as it is accessed and keeping track of this information in an audit log.
appraisal of files, which allows to prevent access when a measurement (hash) or digital signature does not match the expected value.
The options are not in the default Debian kernel and also IMA has some overhead. So would require a custom kernel.
Can we recompile existing Debian kernel sources with default configuration (or only minimal changes)? I mean without any kernel source code level (such as linux-hardened) enhancements?
Can this be automated?
Would this provide better security? An argument I have read in past was: self-compiled kernel → different entropy → different (unique) kernel map → harder to exploit a self-compiled kernel than a kernel from a public distribution repository. Would this argument apply?
If yes, this could be done on the user’s local machine. (This idea is in this very post is not about adding a kernel to deb.whonix.org Whonix repository.)
If yes, we could also write a feature request against Debian asking to provide package / feature to compile the kernel on the local machine on upgrades rather than using a pre-compiled kernel from the repository.
Yes although the Whonix kernel would still be public so we’d be relying on Whonix being obscure enough that the malware doesn’t know about it.
I failed to make this one important detail clear in my previous post. Will edit to add.
Kernel compilation is supposed to happen on the user’s local machine. This idea does not add a public kernel to deb.whonix.org.
Then that would be far better but most users won’t compile their own kernel.
Ideally they wouldn’t notice that their operating system is compiling the kernel from source instead of downloading prebuild kernel. (Unless they read source code.) Should be fully automated m
Compiling the kernel can take a long time. Especially with the default Debian config and especially in a virtual machine with limited resources.
When I was compiling linux-hardened for testing, it would take nearly the whole day to compile.
The only way this can be done without it being too noticeable is if we slim down the configs a lot which would also reduce attack surface. We can remove all actual hardware options and only support VMs which would considerably reduce the time to compile.
We can make our own whonix-kernel package and make it conflict with other kernel packages.
The package would automate 8.10. Compiling a Kernel and 8.11. Installing a Kernel with our own custom, slimmed down config.
Sounds good, but I am not convinced yet that package should conflict with Debian provided kernels. For user freedom, easy debugging / comparison co-installation should be possible.
Even multiple Debian kernels (various versions) installed at the same time don’t cause issues. A higher version number (or something) can make it the grub default boot option.
I’m working on a custom kernel config. I’m currently compiling it. I’ve gotten rid of a few thousand config options from the default debian config.
Should I enable the KSPP recommend settings and some other hardening settings too?
Not sure. But not important at this time. Could be done on future iteration. Or different packages / options?
Since non-Whonix specific… Any package name ideas?
I guess instructions or automation through a package for a hardened Linux could be interesting for many not wanting or not affording grsec subscription.
Perhaps start with less hardening that works for many users first to get a wide user base and potentially break things through hardening later to have more eyeballs watching?
It isn’t necessarily Whonix specific but it will be VM specific. Maybe something like “hardened-kernel” or “whonix-kernel”.
Here is the kernel configuration I’m working on: Debian paste error
I’ve just tested it on virtualbox and the only error I’m seeing so far is whonix-firewall failing to load since IPv6 isn’t included in the kernel config at all.
It looks like whonix-firewall just blocks IPv6 traffic but what is the point of this when IPv6 is disabled?
Better. Just let’s not use linux-hardened since another project has already taken that name.
Just in case. Can’t be careful enough.
As one of the most weird leaks ever (Whonix was unaffected but still), see this one:
https://lists.torproject.org/pipermail/tor-talk/2014-March/032503.html
It’s related to this:
Leak Tests
Could replace
ipv6
with
ipv6 || true
Note: http://ip6only.me works in Tor Browser. No need to break that. Not sure that requires kernel support.
How does that work: Tor Browser talks to Tor directly (more or less, effectively yes, anon-ws-disable-stacked-tor). And some Tor exit relays support IPv6. Even if Whonix-Gateway has IPv6 disabled, Tor can tunnel IPv6 through its IPv4.
Whonix-Workstation does not have IPv6 disabled.
I don’t see how an IPv6 leak would be possible when the code doesn’t even exist in the kernel.
ip6tables would still spam the logs with errors.