It’s a default by Debian.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801906
Documented how to make journal persistent here:
1 Like
I found the problem. For some reason, the page_poison=1 boot parameter is stopping linux-hardened from booting.
It works fine when I use this boot parameter on my host with linux-hardened. I think it might be something to do with the kernel configuration.
I’m not sure exactly what configuration the debian packaging is looking for. If we can find where it’s meant to be, we can probably add this config there and try compiling it again.
1 Like
I figured out where Debian looks for the config files. It’s in the directory you compile the kernel in and it’s called .config. I didn’t see it before as files that start with dots are hidden by default.
I’ll try compiling the kernel again but with the correct config.
1 Like
Using the correct config is even worse. I get this error
mount: mounting /dev/sda1 on /root failed: No such device
Failed to mount /dev/sda1 as root file system.
Then I get dropped into the initramfs prompt.
I tried clearing all of our custom boot parameters but it didn’t work. I also tried manually specifying the init and root with init=/sbin/init root=/dev/sda1 as boot parameters but that didn’t work either.
The systemd logs are here (I removed the abundance of “Opening SocksPort” Tor logs) but I can’t find anything except systemd’s “live-config-getty-generator” and virtualbox-guest-utils failing somehow.
1 Like
No idea. Some guesses.
madaidan via Whonix Forum:
Using the correct config is even worse. I get this error
mount: mounting /dev/sda1 on /root failed: No such device Failed to mount /dev/sda1 as root file system.
Different grub boot parameters?
The systemd logs are here (I removed the abundance of “Opening SocksPort” Tor logs) but I can’t find anything except systemd’s “live-config-getty-generator” and virtualbox-guest-utils failing somehow.
Possibility that this is actually the journal of a previous boot with
functional kernel?
Other ideas:
Download pre-compiled kernel from linux-hardened and see if that boots
compared to self-compiled one.
Test in another virtualizer first.
Test on the host first.
Figure out serial console login to Linux on functional kernel.
Then serial console login to Linux on broken kernel (to gather more output).
Ask linux-hardened. Perhaps they find the idea of us hosting a Debian
package a cool idea to get more users and support this use case.
1 Like
I’ve tried different boot parameters.
No, the linux-hardened kernel version was 5.2.5 and the functional Debian kernel version was 4.19. You can see the kernel version at the top of the logs.
Also, this problem isn’t because of using a newer kernel as I managed to boot into the 5.2.5 kernel before just by removing page_poison=1.
I don’t think linux-hardened provides pre-compiled kernels. On their releases page, I only see a kernel patch meant to be used in compilation of an ordinary kernel.
linux-hardened always worked fine in different virtualizers for me so I don’t think that’s the problem. Although I never tested it on Debian before.
It works fine on my host.
I’m not sure how that would help.
1 Like
1 Like
1 Like
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?
1 Like
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.
1 Like
1 Like
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.
2 Likes
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.
1 Like
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.
1 Like
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.
1 Like
Then that would be far better but most users won’t compile their own kernel.
1 Like
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
1 Like
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.
1 Like
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.
1 Like
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.
1 Like