Hacker News Reader

Comment by jws | Hacker News Reader

In a nutshell: This watches critical kernel data and reports or acts on atypical changes to normally static data.

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.

View on HN

Neat, but for everyone writing kernel modules: can this be a BPF program?

Looking at what LKRG does, it sounds like it can.

At my employer, asking us to add a kernel module to our BaseAMI (since this needs to run on every instance) is a very hard sell. Asking us to add a BPF program, which comes with security by design, is much much easier. Or put it this way: we add zero kernel modules to our BaseAMI, but last I counted we were at 15 BPF programs (and Facebook has over 40.)

Wasn't familiar with BPF programs until I saw your comment, and subsequently went on a search trail. Really like what I've read. BPF and XDP provide so much utility!

I thought Jessie had a good overview[0] of BPF

[0] https://blog.jessfraz.com/post/linux-observability-with-bpf/

Brendan Gregg literally wrote the book on BPF: http://www.brendangregg.com/bpf-performance-tools-book.html

He is an engineering god.

Android also uses BPF for a couple of features.

https://source.android.com/devices/architecture/kernel/bpf

The threat model [1] page describes more details about what it's intended to do. I think if there's no false positives for the checks (or false positives are limited to other kernel features which can be disabled), it would be great if LKRG just generated an NMI.

I'm curious about how this is received, though. Has it been discussed on LKML? Are there any distros interested?

[1] https://openwall.info/wiki/p_lkrg/Threat_model

Why not setup a page write access exception?

Genuine question, what are the litations?

If a user mode process already managed to touch kernel data, that means it bypassed page access restrictions somehow. Runtime integrity checks are a way to detect that

But couldn't they just patch out the calls to LKRG code too? That way it would never run.

Of course. This is simply a cat and mouse game at this stage. PatchGuard on Windows has the same weakness, and its defense is simply by being implemented through very obscure means. Pretty much every version of Windows has changed the techniques being used, so disabling PatchGuard is very much hitting a moving target.

So yes you could, but you'd have to know it was running in the first place.

The suggestion elsewhere to create an eBPF variant might be interesting to explore.

I think it would be interesting to have a processor that allowed you to specify a page mask of immutable pages once you cross a one-way privilege/ring threshold.

Does such a MMU/proc feature exist already? Seems like a feature like LKRG would be pretty effective in a case like that.

And if so the big remaining risk would be to the boot device chain security (which LKRG considers out of scope and for which several processors/SoCs already have covering security features).

I'm not sure how this plays out as open source.

In closed source you have a bit of leverage (defender advantage) - changes which might be relatively easy for you to implement could take a long time to completely reverse-engineer to the point they can be beaten.

In the open source world, even the design discussions are going to be out in the open.

And as a user, you want this to be obscure enough that people don't routinely publish bypasses, but well-used enough that it's properly maintained and reviewed.

Seems like it might be hard to thread that needle.

I'm not sure either, if I'm honest.

Patchguard isn't 100% about malware. In the XP-- days, antivirus/firewall vendors did all kinds of DKOM to install their hooks. This resulted in Windows being unstable in some cases, so with Vista Microsoft provided well defined hook points or highlighted existing ones like PsSetLoadImageNotifyRoutine (and deprecated the awful TDI stack for network inspection). The message at the time was "Dear AV people: use these defined hooks please" and Patchguard was basically "and we really mean it - DKOM is dead, stop doing it". It basically means you have a choice when distributing stable software: try to hack around with the kernel, risk bluescreening all your customers either because patchguard changed under you or you failed to correctly disable it etc, or you comply and use the blessed apis. Needless to say one is far less risky.

It also provides a bit of a speed bump for malware. To what extent this will do so for Linux is hard to say. There's plenty of public information on reverse engineering PatchGuard (https://github.com/tandasat/PgResarch, https://github.com/hfiref0x/UPGDSED for starters), and as you say this will likely come with public documentation of its inner workings.

I think this is interesting, but I think efforts like syzkaller and other "kernel hardening" efforts (to find correctness issues and fix bugs as fast as possible) are more valuable.

Reply on news.ycombinator.com