The project Openwall has released the LKRG 0.8 kernel module release (Linux Kernel Runtime Guard), designed to detect and block attacks y violations of the integrity of the core structures.
The it is suitable both for organizing protection against already known exploits for the Linux kernel (for example, in situations where updating the kernel on the system is problematic), as for opposing exploits for unknown vulnerabilities.
What's new LKRG 0.8?
In this new version the positioning of the LKRG project has been changed, thathour is not divided into separate subsystems to verify integrity and determine the use of exploits, but it is presented as a complete product to identify attacks and various integrity violations;
Regarding the compatibility, of this new version, we can find that it is compatible with Linux kernels from 5.3 to 5.7as well as kernels compiled with aggressive GCC optimizations, without the options CONFIG_USB and CONFIG_STACKTRACE or with the option CONFIG_UNWINDER_ORCas well as with kernels where there are no functions intercepted by LKRG if you can do without.
In addition to the experimental support for 32-bit ARM platforms (tested on Raspberry Pi 3 Model B), while for earlier available support for AArch64 (ARM64) is complemented by compatibility with Raspberry Pi 4.
Moreover, new hooks have been added, which include a "hook ()" call handler to better identify vulnerabilities that are manipulated by "capabilities", rather than process identifiers.
On x86-64 systems, the SMAP bit is checked and applied (Prevention of access in supervisor mode), ddesigned to block access to data in user space from privileged code executed at the kernel level. SMEP (Supervisor Mode Execution Prevention) protection was implemented earlier.
Has increased scalability of the process tracking databaseInstead of a single RB tree protected by a spinlock, a hash table of 512 RB trees is involved, protected by 512 read and write locks, respectively;
A default mode is implemented and enabledIn which the integrity check of identifiers Processing is often performed only for the current task, and also optionally for triggered tasks (wake up). For other tasks that are in a suspended state or that function without an LKRG controlled kernel API call, verification is performed less frequently.
In addition to the systemd unit file has been redesigned to load the LKRG module at an early stage of loading (the kernel command line option can be used to disable the module);
During compilation, a check was performed on some of the mandatory CONFIG_ * kernel settings to generate meaningful error messages rather than obscure faults.
Of the other changes that stand out in this new version:
- Added support for Standby (ACPI S3, Suspend to RAM) and Suspend (S4, Suspend to Disk) modes.
- Added support for DKMS in the Makefile.
- New logic is proposed to determine attempts to get out of namespace restrictions (for example, from Docker containers).
- In the process, the LKRG configuration is placed on a page of memory, usually read-only.
- The output to logs of information that may be most useful for attacks (for example, address information in the kernel) is limited by debug mode (log_level = 4 and higher), which is disabled by default.
- New sysctl and module parameters have been added to tune LKRG, as well as two sysctl for simplified configuration by choosing from profiles prepared by developers.
- The default settings are changed to achieve a more balanced balance between the speed of violation detection and the effectiveness of the reaction, on the one hand, and the impact on productivity and the risk of false positives on the other.
- According to the optimizations proposed in the new version, the performance decrease when applying LKRG 0.8 is estimated at 2.5% in the default mode ("heavy") and 2% in the light mode ("light").
If you want to know more about it, you can consult details here.