LKRG performs runtime integrity checking of the Linux kernel and detection of security vulnerability exploits against the kernel.
Being a kernel module (not a kernel patch), LKRG can be built for and loaded on top of a wide range of mainline and distros' kernels, without needing to patch those. We currently support kernel versions ranging from as far back as RHEL7's (and its many clones/revisions) and Ubuntu 16.04's to latest mainline and distros' kernels.
Download (release notes, previous release notes):
These and older versions of LKRG are also available from the Openwall file archive. The source code and revision history of LKRG may be browsed on Bitbucket.
Follow this link for information on verifying the signatures.
Please check out our presentation slides on LKRG.
There's a mailing list where you can share your experience with LKRG and ask questions. Please be sure to specify an informative message subject whenever you post to the list (that is, something better than "question" or "problem"). To subscribe, enter your e-mail address below or send an empty message to <lkrg-users-subscribe at lists.openwall.com>. You will be required to confirm your subscription by "replying" to the automated confirmation request that will be sent to you. You will be able to unsubscribe at any time and we will not use your e-mail address for any other purpose or share it with a third party. However, if you post to the list, other subscribers and those viewing the archives may see your address(es) as specified on your message.
We may help you setup LKRG on or integrate it into your systems and/or customize it as it may be necessary for your needs. Please check out our services.
As controversial as this concept is, LKRG attempts to post-detect and hopefully promptly respond to unauthorized modifications to the running Linux kernel (integrity checking) or to credentials such as user IDs of the running processes (exploit detection). For process credentials, LKRG attempts to detect the exploit and take action before the kernel would grant access (such as open a file) based on the unauthorized credentials.
LKRG defeats many pre-existing exploits of Linux kernel vulnerabilities, and will likely defeat many future exploits (including of yet unknown vulnerabilities) that do not specifically attempt to bypass LKRG. While LKRG is bypassable by design, such bypasses tend to require more complicated and/or less reliable exploits.
LKRG also provides security through diversity, much like running an uncommon OS kernel would, yet without the usability drawbacks of actually running an uncommon OS. As free LKRG becomes somewhat popular and maybe a target of some exploits, we might introduce paid LKRG Pro as a means to fund the project and provide further diversity (with Pro's smaller userbase being beneficial), extra and specialized functionality, and maybe distro-specific binary builds.
Like any software, LKRG may contain bugs and some of those might even be new security vulnerabilities. You need to weigh the benefits vs. risks of using LKRG, considering that LKRG is most useful on systems that realistically, despite of this being a best practice for security, won't be promptly rebooted into new kernels (nor live-patched) whenever a new kernel vulnerability is discovered.
LKRG is currently in an experimental stage. We expect occasional false positives (integrity violations and/or exploits detected when there aren't ones). LKRG's current default response to kernel integrity violations is merely reporting those in kernel messages (which obviously doesn't mitigate real attacks), but LKRG may be configured to panic the kernel instead. LKRG's current response to unauthorized process credentials is killing the process (which does defeat many exploits, but is a rather mild response nevertheless). LKRG's default response is changing as LKRG becomes more mature. In fact, current LKRG will by default panic the kernel if it finds SMEP (Supervisor Mode Execution Protection, a security feature of recent CPUs) unexpectedly disabled. We dare to do this because we reasonably expect no false positives with that specific LKRG feature.
To illustrate LKRG's exploit detection capabilities, in our testing on vulnerable distro kernels LKRG successfully detected certain pre-existing exploits of CVE-2014-9322 (BadIRET), CVE-2017-5123 (waitid(2) missing access_ok), CVE-2017-6074 (use-after-free in DCCP protocol). However, it wouldn't be expected to detect exploits of CVE-2016-5195 (Dirty COW) since those directly target the userspace even if via the kernel. While in case of Dirty COW the LKRG "bypass" happened due to the nature of the bug and this being the way to exploit it, it's also a way for future exploits to bypass LKRG by similarly directly targeting userspace. It remains to be seen whether such exploits become common (unlikely unless LKRG or similar become popular?) and what (negative?) effect on their reliability this will have (for kernel vulnerabilities where directly targeting the userspace isn't essential and possibly not straightforward).
To give you a rough idea of LKRG's performance impact, building John the Ripper 1.8.0-jumbo-1 with "./configure CFLAGS='-O0'" (that is, with compiler optimizations disabled in order to artificially reduce the amount of processing in userspace and increase the frequency of syscalls, thereby exposing LKRG's possible performance impact more) and "make -j8" on an Atom C2750 machine (8 Silvermont cores) running VzLinux (Virtuozzo 7) with LKRG 0.2 appears to be around 2.5% for fully enabled LKRG, or around 0.7% for LKRG with code integrity checks on random events disabled with the corresponding sysctl.