Linux Kernel Runtime Guard (LKRG) - Linux Kernel Runtime Integrity Checking and Exploit Detection

1 Like

2 Likes

got reply:
https://www.openwall.com/lists/lkrg-users/2019/11/14/5

2 Likes

Probably due to #5456 / #2844. This might be fixed after upgrades.


1 Like

2 Likes

https://www.reddit.com/r/linux/comments/dz7yh3/linux_kernel_runtime_guard_lkrg_kills_whole/

1 Like

Nobody in that thread even read past the first few lines…

1 Like

Very few of the commenters indeed looks like. Following links, let alone reading footnotes, using search engines… Didn’t notice much of that there.

1 Like

Welcome to reddit :smiley:

1 Like

LKRG can cause this:

sudo iptables --list

iptables/1.8.2 Failed to initialize nft: Protocol not supported

Cause:

lkrg.umh_lock=1
1 Like

That setting seems pointless anyway as the Debian kernel doesn’t even have usermode helpers enabled.

1 Like

Bug on Qubes, Debian buster.

cat /proc/version

Linux version 5.3.0-0.bpo.2-amd64 (debian-kernel@…ts.debian.org) (gcc
version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 5.3.9-2~bpo10+1 (2019-11-13)

cat /proc/cmdline

BOOT_IMAGE=/boot/vmlinuz-5.3.0-0.bpo.2-amd64 root=/dev/xvda3 ro
xen_scrub_pages=0 root=/dev/mapper/dmroot console=hvc0 console=tty0
swiotlb=8192 noresume intel_iommu=on amd_iommu=on slab_nomerge
slub_debug=FZ init_on_alloc=1 init_on_free=1 mce=0 pti=on mds=full,nosmt
vsyscall=none page_alloc.shuffle=1

[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 !!!

reported upstream:
https://www.openwall.com/lists/lkrg-users/2019/12/23/1

2 Likes

Couldn’t write ‘0’ to ‘lkrg/clean_message’, ignoring: No such file or directory

2 Likes

Any reference for that? Asking because then I can add that to Linux Kernel Runtime Guard (LKRG) for Debian, Whonix, Qubes, Kicksecure.

1 Like

Actually, I was wrong. I was thinking of a static usermodehelper which is different from usermodehelpers in general.

2 Likes

Possible to load LKRG through systemd-modules-load.service / /usr/lib/modules-load.d / /etc/modprobe.d as last module?
https://www.openwall.com/lists/lkrg-users/2020/01/11/1

2 Likes

LKRG complains about battery being automatically unload
https://www.openwall.com/lists/lkrg-users/2020/01/11/2

2 Likes

Thanks to @madaidan for posting this on telegram.

In case anyone wondering: no, I don’t think this speaks against LKRG. This was expected. As per Linux Kernel Runtime Guard (LKRG) for Debian, Whonix, Qubes, Kicksecure LKRG quote

LKRG renders whole classes of kernel exploits ineffective

read more

Still applies.

2 Likes

https://github.com/Whonix/lkrg/commit/99439fe2d95f5f588f4e3d3f15842e336da07acc

1 Like

A blocker for installation onf LKRG by default in Non-Qubes-Whonix Whonix-Gateway:

I experienced the VM freezing during LKRG installation. Freezes GUI (seconds counter at the clock freezes and will never move on again.) Happening in a VirtualBox VM during LKRG DKMS compilation with 768 MB RAM and 512 MB swapfile. Not always reproducible. I provided various SysRq output to LKRG upstream in private e-mail. Not sharing here as it might contain sensitive information about my system.

While swap gets used, swap does not run out of memory. Check in another console tab using:

while true ; do free -m && sleep .2 ; done

Gathered the log using a serial console. Journal does not have anything interesting.

This doesn’t happen when increasing RAM. Whonix-Gateway VirtualBox by default comes with 768 MB RAM and a 512 MB encrypted swapfile. Whonix-Workstation VirtualBox by default comes 2048 MB RAM and no swapfile. (By adding >= 2000 MB RAM to Whonix-Gateway, no swap file will be created by swap-file-creator (Whonix github project). I’d very much like to increase default RAM of Whonix-Gateway to 2048 MB RAM but that won’t work out of the box for many of Whonix users. Let’s say someone has host system with 4 GB RAM which is quite common. Hard to run two VMs there. Kernel Samepage Merging (KSM) might be available for VirtualBox too, but there were some security issues with it. Some references.

LKRG compilation should be possible even though swap is required? Maybe LKRG isn’t the cause but only the trigger? 768 MB RAM for a Debian VM with XFCE might be too little RAM nowadays?

It could be this bug - a long standing kernel bug related to system stress and swap:
https://bugzilla.kernel.org/show_bug.cgi?id=196729

A bug which might not be fixed anytime soon. That would be a blocker for Non-Qubes-Whonix Whonix-Gateway LKRG installation by default. Then LKRG could could be installed by default in Non-Qubes-Whonix Whonix-Workstation. (LKRG in Qubes-Whonix has its own blockers for installation by default.)

Maybe another hack could be to install the LKRG package by default but only attempt to actually compile it if enough RAM is available so that it would at least be usable by those who have the system resources to assign sufficient RAM.

2 Likes