Linux kernel runtime guard

LKRG performs runtime integrity checking of the Linux kernel and detection of security vulnerability exploits against the kernel.

LKRG is a kernel module (not a kernel patch), so it 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.

We’ve tested LKRG 0.9.5 with Linux kernels up to and including 5.19.

LKRG currently supports the x86-64, 32-bit x86, AArch64 (ARM64), and 32-bit ARM CPU architectures.

These and older versions of LKRG are also available from the Openwall file archive. The source code and revision history of LKRG can be browsed on GitHub.

Follow this link for information on verifying the signatures.

We tweet LKRG project news via @lkrg_org. We also announce LKRG releases on Openwall’s announce and lkrg-users mailing lists.

The lkrg-users mailing list is also a place 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 . 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.

LKRG packages exist in ALT Linux, Arch Linux, Astra Linux, Funtoo, Gentoo, Guix, Whonix, and Yocto (and thus also OpenBMC). Whonix’s packaging is also usable for Debian and its other derived distributions (including Ubuntu).

Why or why not LKRG?

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.

Master’s Thesis of Juho Junnila, entitled «Effectiveness of Linux Rootkit Detection Tools», shows LKRG as the most effective kernel rootkit detector (of those tested).

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 possibly starts being deliberately bypassed by 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. Moreover, usage of any out-of-tree kernel module involves risk of incompatibilities with the specific kernel version/build, and LKRG is no exception. We test LKRG across a wide range of kernel versions, but obviously not with future kernel versions, with which LKRG might or might not work right. 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), especially with Linux kernel versions or configurations other than those we’ve tested. Please keep this in mind when configuring LKRG’s response to detected violations, such as starting with mild enforcement and only enabling stricter enforcement once you’ve confirmed you are not seeing false positives.

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).

The overall performance impact of LKRG 0.8 as seen from the geometric mean of 58 test results from Phoronix Test Suite on a Xeon E-2176G with Ubuntu 18.04 is around 2.5% for LKRG’s heavy profile (which is the default) and around 2.0% for the light profile, although the individual test results vary. Phoronix also published a different set of benchmarks with as many as 119 tests.

Источник

Linux Kernel Runtime Guard (LKRG) for Debian, Whonix, Qubes, Kicksecure

Introduction [ edit ]

LKRG is Freedom Software / Open Source. [1]

The focus of this wiki page is to provide simplified user documentation and easy installation of LKRG in Debian, Kicksecure, Qubes, Whonix, and perhaps Debian-based Linux distributions. Installable from an APT repository.

This is a lightweight software fork and no changes will be made to the core of LKRG. Links to the official LKRG homepage and other original resources can be found here.

Download [ edit ]

LKRG Overview [ edit ]

This is only a very brief introduction, since LKRG technical details are not the focus of this page. Quote official LKRG homepage :

LKRG 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 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.

To learn more about LKRG, interested readers can:

review the official LKRG homepage
watch the LKRG Presentation Video or LKRG Presentation Slides
read the LKRG Wiki
LKRG rootkit detection
consult other Upstream Resources
LKRG is also mentioned in Master’s Thesis Effectiveness of Linux Rootkit Detection Tools

Performance Impact [ edit ]

Quote LKRG upstream:

No benchmarks have yet been performed, but it appears the performance penalty is around 2.5% for fully enabled LKRG.

Quote Phoronix.com , Benchmarking The Performance Overhead To The Linux Kernel Runtime Guard (page 5 ), Michael Larabel ( code added):

Out of 90 benchmarks run comparing the performance hit on this Intel Core i9 9900KS from LKRG, having LKRG enabled led to around a 5% hit based on the geometric mean of all tests carried out. Granted, some real-world workloads like code compilation speed were impacted much more dramatically while test cases not involving I/O or other kernel operations tended to see no measurable difference in run-time performance.

LKRG Free vs LKRG Pro [ edit ]

Kicksecure ™ developer Patrick Schleizer said :

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».

We will likely use GPLv2 at least for LKRG free. We might or might not use a different license for LKRG Pro, if we ever make it.

Users who benefit from LKRG Free are encouraged to support its further development. However, at the time of writing they are not accepting donations: [2]

We used to accept donations for LKRG via Patreon, but we currently don’t. Some of our former supporters are listed in the PATREON file in LKRG distribution tarballs.

Installation [ edit ]

Warning: This is for testers-only!

Note: Users who require better security can Build the Linux Kernel Runtime Guard (LKRG) Debian Package from Source Code and verify software signatures before installation.

Host Operating System	Installation Instructions	Note
Debian hosts	Follow the instructions below to install from the Kicksecure ™ repository. [3]	If intending to run the VirtualBox host software (such as for running Kicksecure ™ virtual machine (VM)) additional configuration is required. [4]
Kicksecure ™	Follow the installation instructions below.	In Kicksecure ™, skip the following «Add Kicksecure ™ repository» step since it is already enabled by default.
Qubes OS Debian based VMs	Follow these LKRG Qubes instructions.	See footnote. [5]
Kicksecure ™ for Qubes	Follow these LKRG Kicksecure ™ for Qubes instructions.	See footnote. [5]
Other Linux distributions	LKRG is available for most Linux distributions.	Follow the installation instructions for non-Debian distributions on the official LKRG homepage .

Add Kicksecure ™ repository.

3. Add Kicksecure ™ signing key.

4. Kicksecure ™ APT repository choices.

Optional: See Kicksecure ™ Packages for Debian Hosts and Kicksecure ™ Host Enhancements instead of the next step for more secure and complex options.

5. Add Kicksecure ™ APT repository.

1. Update the package lists.

The LKRG installation is complete. [9]

It is recommended to review optional hardening and other entries below, but this is not required.

Configuration [ edit ]

It might be possible to further improve the security provided by LKRG though LKRG configuration, but this can potentially lead to decreased system stability. Note: Unspecific to Kicksecure ™.

These configuration sysctl where up to date at time of writing but might be outdated in future LKRG releases. Please refer to upstream sysctl configuration documentation chapter Runtime configuration and upstream configuration file /etc/sysctl.d/30-lkrg-dkms.conf .

General LKRG Configuration Tips [ edit ]

Note: All the possible configuration changes in this section are optional.

Table: General LKRG Configuration Tips

Category	Instructions
View Current Runtime Configuration	To view the current configuration, run.

Refer to upstream readme chapter Runtime configuration .

Temporary Runtime Configuration Changes To temporarily change configuration settings until next reboot, run.

Note: Replace lkrg.pcfi_validate=1 with the actual sysctl setting you like to change as per upstream documentation.

Persistent Configuration Changes To enable any (LKRG) sysctl persistently after reboot.

Open file /etc/sysctl.d/50_user.conf in an editor with root rights.

This box uses sudoedit for better security. This is an example and other tools could also achieve the same goal. If this example does not work for you or if you are not using Kicksecure ™, please refer to this link.

Paste (LKRG) sysctl settings such as.

Note: Replace lkrg.pcfi_validate=1 with the actual sysctl setting you like to change as per upstream documentation.

The procedure of persistently changing sysctl settings is complete.

VirtualBox host software compatibility

Not required for VirtualBox guest VM. [10]

Kicksecure specific LKRG Configuration Tips [ edit ]

Table: Kicksecure ™ specific LKRG Configuration Tips

Category	Instructions
Block Module Loading	Users which use lkrg.block_modules in Kicksecure ™ would also have to follow Kicksecure ™ instructions on module loading.
Hardening — UMH Validation and Enforcement	Better do not use lkrg.umh_validate=2 for now. Might break Kicksecure ™ Firewall. Advanced users could refer to upstream documentation on lkrg.umh_validate and lkrg.umh_enforce .

Usage [ edit ]

Once LKRG has been installed, little effort is required since it will protect the kernel without the user’s knowledge and/or interaction. However, it is sensible to check that LKRG is running correctly and to monitor system logs for any suspicious entries. Check this entry at a later date for any additional recommendations.

To check systemd journal log for kernel messages by LKRG, run.

To keep watching systemd journal log for new LKRG messages, run.

At this stage a graphical user interface (GUI) is not provided that can proactively inform users who fail to analyze the systemd journal log for relevant LKRG messages. A GUI or popup notification might be developed later on — help is most welcome.

Recovery [ edit ]

Quote upstream readme:

To account for the hopefully unlikely but really unfortunate event that some incompatibility between the Linux kernel or other components of the system and LKRG isn’t detected prior to LKRG installation yet leads to system crash on bootup, we’ve included support for the » nolkrg » kernel parameter in the systemd unit file for LKRG. Thus, if you’ve followed the above installation procedure for LKRG with systemd, you may disable LKRG by specifying » nolkrg » on the kernel command-line via your bootloader. The system should then boot up without LKRG, and thus without triggering the problem, letting you fix it.