madaidan via Whonix Forum:
Merged.
kernel recompilation for better hardening
1 Like
madaidan via Whonix Forum:
security-misc enables it after X starts which isn’t as good as having it enabled all the time.
I see. Maybe better add this as a sysctl, in a package that gets only
installed inside VMs? (then it would also be enabled in initramfs
already) Reason is that this would be way more easy to disable / debug /
port.
Do we have other (security) settings too which are VM-only?
Do we have other (security) settings too which are host-only?
Also we yet have to create security-paranoid(opt-in package for settings
which are too experimental for security-misc default package?
1 Like
1 Like
hardened-kernel 0.8-1 on Non-Qubes-Whonix Whonix-Gateway and Whonix-Workstation.
DKMS does not run during linux kernel package upgrade. Therefore after reboot LKRG and tirdad no longer functions.
Jan 15 13:36:06 host modprobe[213]: modprobe: ERROR: could not insert ‘p_lkrg’: Exec format error
Workaround until DKMS will be properly run after kernel package upgrade:
sudo apt install --reinstall lkrg-dkms tirdad-dkms
Tirdad is fixed after that procedure.
DKMS might not run since the package is installed directly by dpkg and not through APT?
Next issue after reboot:
sudo modprobe p_lkrg
modprobe: ERROR: could not insert ‘p_lkrg’: No buffer space available
1 Like
Users can set kernel.panic_on_oops=0 if they need to disable it.
Not really.
That isn’t really needed since we can just add those settings to security-misc but make them opt-in.
madaidan via Whonix Forum:
Users can set
kernel.panic_on_oops=0if they need to disable it.
I see. That is good enough.
I was previously (probably falsely) assuming that this value would then
be hardcoded and users would need to recompile the kernel.
That isn’t really needed since we can just add those settings to security-misc but make them opt-in.
I.e. instruct users to copy from one place to another?
1 Like
No, this doesn’t get rid of the kernel.panic_on_oops sysctl.
No, as in telling them to do things like enable certain systemd services (e.g. hide-hardware-info) or uncomment certain lines (e.g. disabling SACK).
1 Like
Randomly found a message from Daniel Micay which talks about what kernel versions to use for security which is pretty relevant.
Relevant parts:
It’s important to follow along with the latest longterm / stable releases of the Linux kernel and the more recent branches are usually better choices because backporting is increasingly incomplete for the older branches. However, new kernel branches also have more attack surface and newer features / code that are less battle hardened. Of the supported upstream kernels (https://www.kernel.org/), I would go with 4.14 and soon 4.19 when it’s a little bit more mature. In terms of out-of-tree drivers, as long as they’re open source (they are), the only real sense it matters is acting as a blocker for migrating to newer LTS branches. Look at which branch https://grsecurity.net/download.php uses for the production variant.
There are both security advantages (new security features, more bug fixes applied) and disadvantages (more attack surface, more complexity, more new bugs) to using a more recent kernel branch. I think the best choice for overall security is usually the most recent LTS branch, once it has been available for a bit, so the best choice would likely be the 4.19 LTS at the moment. There’s so much churn and so many regressions when following mainline even just in terms of what people run into during regular use and it certainly applies to the underlying security properties of the kernels.
It seems like we’re using the best kernel version (currently 4.19).
2 Likes
This is awesome! Thanks @madaidan! This will help to get more eyes on it and result in wider exposure / better testing.
2 Likes
I had archives in git repository and no download on user’s machine implemented but github crossed out my plans when trying to git push.
remote: error: GH001: Large files detected. You may want to try Git Large File Storage - https://git-lfs.github.com.
remote: error: Trace: 980557540f5f13fe7ad779afff4213be
remote: error: See http://git.io/iEPt8g for more information.
remote: error: File usr/src/hardened-kernel/files/linux-4.19.93.tar is 801.99 MB; this exceeds GitHub’s file size limit of 100.00 MB
Various options come to mind as a solution… No amazing option yet will keep looking…
1 Like
- git-annex (in Debian) can add files to git without really adding them. git push and git clone would work with any popular free git service such as github. However, those who clone the repository would not really have the required files. These would still have to be downloaded. Does not seems like the best solution for our use case.
- github with git LFS. 1 GB storage (would be OK) with 1 GB traffic quota per month.
- fork https://github.com/anthraxx/linux-hardened and
git checkout 4.19.96.a. Then add our compilation script and packaging on top. When new version comes out, we just git rebase to new tag. We wouldn’t save any space in the repository but we would satisfy that particular github hardlimit.
How did you come to that conclusion? I can’t find any documentation by hardened-linux.
2 Likes
git clone --depth=1 https://github.com/anthraxx/linux-hardened.git
cd linux-hardened
git fetch origin tag --depth=1 --no-tags 4.19.96.a
git verify-tag 4.19.96.a
git verify-commit 4.19.96.a^{commit}
git checkout 4.19.96.a
git branch 4.19.96.a
That should be as good as kernel archive from kernel.org + linux-hardened patch? Should b really the same?
Upon reflection… Maybe not fork linux-hardened. Just git clone and checking out the git tag which were are interested in. Then add linux-hardened as a git submodule to our hardened-kernel. That is because linux-hardened has .gitignore folder which contains the /debian folder and make deb-pkg creates the /debian folder. That conflicts with our hardened-kernel packaging. Rather than hack around that it seems better to not touch linux-hardened (except checkout proper version) and use a git submodule. Even though git submodules don’t have the best usability that would get the task done.
2 Likes
Upload the .tar.xz and instead of the .tar file.
madaidan via Whonix Forum:
Upload the .tar.xz and instead of the .tar file.
That might even work for now but it’s not a future proof solution. Linux
tarball seems to be growing. Breaking the 100 MB border soon.
97M linux-4.14.165.tar.xz
105M linux-5.4.12.tar.xz
167M linux-5.5-rc6.tar.gz
That would break with Linux 5.x series. And I’d rather not implement
something that will need changes soon.
I see. Well, arch linux might have different requirements.
1 Like
2 Likes
1 Like
Quote https://cateee.net/lkddb/web-lkddb/RESET_ATTACK_MITIGATION.html
CONFIG_RESET_ATTACK_MITIGATION
Request that the firmware clear the contents of RAM after a reboot using the TCG Platform Reset Attack Mitigation specification. This protects against an attacker forcibly rebooting the system while it still contains secrets in RAM, booting another OS and extracting the secrets. This should only be enabled when userland is configured to clear the MemoryOverwriteRequest flag on clean shutdown after secrets have been evicted, since otherwise it will trigger even on clean reboots.
Specifically:
This should only be enabled when userland is configured to clear the MemoryOverwriteRequest flag on clean shutdown
Can you make head or tail of that?
since otherwise it will trigger even on clean reboots.
I would think this is a feature, not a bug.
1 Like
Both merged, thanks! 
Could you please re-enable this in the debug kernel config, i.e. no /dev/mem restriction in the debug kernel?
1 Like