Linux Kernel Runtime Guard 0.9.0 Is Released
Linux Kernel Runtime Guard (LKRG) is a security module for the Linux kernel developed by Openwall. The latest release adds compatibility with Linux kernels up to soon to be released 5.12, support for building LKRG into kernel images, support for old 32-bit x86 machines and more. Loading the LKRG 0.9.0 module will cause a kernel panic and a complete halt if SELinux is enabled.
src/modules/exploit_detection/p_exploit_detection.c from LKRG 0.9.0.
|Update: The unfortunate problem with SELinux described in this article is fixed in the LKRG git tree and a 0.9.1 release will be announced shortly. The current git tree works fine with SELinux.
"During the refactor work, we forgot to snapshot the original state of SELinux on the initialization phase. This bug is only triggered if SELinux is already in enforcing state when LKRG is loaded, and only on Linux 4.17+. We've just fixed that issue (trivial change) and we want to quickly release updated version (0.9.1) to make sure that users of LKRG won't encounter that problem."
The Linux Kernel Runtime Guard is an out-of-tree kernel module you can install as a kernel module, or, with the 0.9.0 release, build into your Linux kernel. It does run-time integrity checks to detect security vulnerability exploits against the Linux kernel. It has a lot of configurable security options. It can, for example, prevent additional kernel modules from being loaded (this is enabled by default). It supports four different profiles for various levels of security.
The latest 0.9.0 release adds support for Linux kernels up to and including next weeks Linux 5.12 release. Older stable Linux kernels are also supported. The release-notes also falsely claim that this version:
"Support new RHEL kernels up to RHEL 8.4's (inclusive)"
That claim may, in theory, be vaguely true. You will quickly find that it's false if you actually try KLRG on RHEL or another distribution where SELinux is enabled by default.
SELinux Is Not Supported
"<Exploit Detection> Detected data corruption against SELINUX! 'selinux_state->enforcing' has different value [1 vs 0] than expected!
[p_lkrg] SELinux Integrity verification failed! Killing the kernel..."
We have no idea why anyone would think that someone using a SELinux enabled distribution like AlmaLinux, RHEL, Fedora or CentOS would be "expected" to have SELinux disabled, and we can't begin to phantom why anyone would think that someone who has intentionally disabled SELinux would be even remotely interested in something like the Linux Kernel Runtime Guard.
Why KLRG would think that someone is trying to exploit the system and force a kernel panic if SELinux is enabled is also a very good question.
LKRG Can Now Be Built Into The Kernel
The biggest highlight in 0.9.0 is support for building LKRG into kernels. This can be done using a script bundled in
scripts/copy-builtin.sh. It assumes your kernel source resides in
/usr/src/linux. Adding it to the kernel tree enumerates a new
SECURITY_LKRG option. You can still choose to build it as a module with
SECURITY_LKRG=m if you build it as part of the kernel tree.
RT Kernels Are Not Supported
The release notes mention Explicitly do not support RT kernels. It does not say why. LKRG has a performance-penalty, the integrity checks it does are not free. It may be that the authors believe the performance impact on real time kernels is too great.
execve hooks formally in the LKRG code have been replaced with
security_bprm_committing_creds and validation of wake-up tasks has been removed.
Does It Work?
The developers note that they have found no less than 7 kernel bugs, for of which serious enough to get CVE numbers, during development:
"During LKRG development and testing I've found 7 Linux kernel bugs, 4 of them have CVE numbers (however, 1 CVE number covers 2 bugs):
- CVE-2021-3411 - Linux kernel: broken KRETPROBES and OPTIMIZER
- CVE-2020-27825 - Linux kernel: Use-After-Free in the ftrace ring buffer resizing logic due to a race condition
- CVE-2020-25220 - Linux kernel Use-After-Free in backported patch for CVE-2020-14356 (affected kernels: 4.9.x before 4.9.233, 4.14.x before 4.14.194, and 4.19.x before 4.19.140)
- CVE-2020-14356 - Linux kernel Use-After-Free in cgroup BPF component (affected kernels: since 4.5+ up to 5.7.10)"
The developers experiences gives us the distinct impression that the LKRG will help if you spend all day trying to break your kernel's security. It does seem likely that it will also help against random exploits and vulnerabilities.
We have not actually tested how well it actually works if you try spend all your time trying to find and exploit kernel vulnerabilities or how well it works in a real-world production environment. What we can say for sure it that it won't work at all in any real-world deployment where SELinux is enabled since LKRG will trigger a kernel panic if SELinux security is enabled. That alone makes it kind of questionable how useful it is anywhere outside of a securitylab setting.
The LKRG module has hooks into all kinds of kernel sub-systems. It is hard to do actual integrity checking without some kind of performance penalty. LKRG 0.9.0 is shockingly light-weight compared to our expectations.
Kernel compilation took 27 seconds longer with LKRG on the Intel i7-5500U test machine and 1 second longer on the Ryzen 2600.
The Linux Kernel Runtime Guard v0.9.0 does not appear to have any noticeable impact on graphics performance. There could, of course, be a larger performance impact on specific work-loads like database servers, web servers and other applications we haven't tested. What we can say is that we did not see any huge performance penalty, or any outside or normal run-to-run variation, in the few tests we did.
The LKRG homepage, with a download link for the source code, is at https://www.openwall.com/lkrg/. The full 0.9.0 release-announcement can be read at at https://www.openwall.com/lists/announce/2021/04/12/1. You will also want to read the lengthy
lkrg-0.9.0.tar.gz since there are quite a few configuration options you will want to be aware of before you deploy it.