Linux Kernel Runtime Guard (LKRG) is a loadable kernel module that performs runtime integrity checking of the Linux kernel and detection of security vulnerability exploits against the kernel. 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 the process access (such as open a file) based on the unauthorized credentials.
While 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, it is bypassable by design (albeit sometimes at the expense of more complicated and/or less reliable exploits). Thus, it can be said that LKRG 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 (e.g., detection of container escapes), and maybe distro-specific binary builds.
I am considering to package LKRG for Debian buster, Whonix, Kicksecure and Qubes Debian templates.
(Inside Qubes OS. Using Qubes VM kernel, i.e. kernel by Debian. See related.)
Initially it will be an opt-in package to encourage wider testing. Should that work well, installation of LKRG by default will be considered.
Current status: Iāve successfully compiled and load the LKRG module in a Qubes Debian standalone VM using Qubes VM kernel.
Outreach:
Contacted upstream LKRG developers privately. To paraphrase: āWe donāt oppose you packaging it. As long as LKRG exists, there will always be a free and libre version. There is no pro version yet. A hypothetical future pro version would not change that.ā In my words: āthere wonāt be a grsecurity alike situation where everything gets closed downā.
LKRG doesnāt seem to be that well known which means less people are reviewing the code so there may be a bunch of vulnerabilities. This is worse as itās a kernel module which would add a lot of attack surface.
It also doesnāt seem to be very mature yet
LKRG is currently in an early experimental stage. We expect occasional false positives (integrity violations and/or exploits detected when there arenāt ones). LKRGās current response to kernel integrity violations is merely reporting those in kernel messages (which obviously doesnāt mitigate attacks when those are for real) and its current response to unauthorized process credentials is killing the process (which does defeat many exploits, but is a rather mild response nevertheless). This will likely change as LKRG becomes more mature.
Iāve read somewhere, that off-the-shelf malware disables itself when LKRG is detected.
Saw the presentation video yet? LKRH is said to disable whole classes of exploits. Requiring a full read/write exploit possibly specifically written to circumvent LKRG.
Also have to research its authors more. openwall / solar designer has an excellent professional track record. I know him a bit from professional experience. Heās of high morals. Yet have to learn more who authored / reviewed LKRG.
A project worth supporting even if turns out not ready for default installation. Canāt say yet. Still learning.
Very few of the commenters indeed looks like. Following links, let alone reading footnotes, using search enginesā¦ Didnāt notice much of that there.
[p_lkrg] ALERT !!! _STEXT MEMORY BLOCK HASH IS DIFFERENT - it is
[0x8daa4a39f8ae8401] and should be [0x25ed90ca36ee0266] !!!
[p_lkrg] ALERT !!! MODULEāS <nf_nat> HASH IS DIFFERENT it is
[0x3d9dae4aaff5f86d] and should be [0xd8e509a7b4d09682] !!!
[p_lkrg] ALERT !!! MODULEāS <nf_conntrack> HASH IS DIFFERENT it is
[0xfe2e9cd1fd5ea173] and should be [0x99dd56638030bb2b] !!!
[p_lkrg] ALERT !!! MODULE LIST HASH IS DIFFERENT !!! - it is
[0x333c093b7373b41b] and should be [0xd42a3b20e4da8541] !!!
[p_lkrg] ALERT !!! MODULE KOBJ HASH IS DIFFERENT !!! - it is
[0x5f13310a27d2344f] and should be [0xbf5da19a4b5e9f8d] !!!
[p_lkrg] [KOBJ] ALERT !!! MODULEāS <nf_conntrack> HASH IS DIFFERENT it
is [0xfe2e9cd1fd5ea173] and should be [0x99dd56638030bb2b] !!!
[p_lkrg] [KOBJ] ALERT !!! MODULEāS <nf_nat> HASH IS DIFFERENT it is
[0x3d9dae4aaff5f86d] and should be [0xd8e509a7b4d09682] !!!
[p_lkrg] ALERT !!! SYSTEM HAS BEEN COMPROMISED - DETECTED DIFFERENT 7
CHECKSUMS !!!
