Linux Kernel Runtime Guard
whonix.org
whonix.org
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.
I'm curious about how this is received, though. Has it been discussed on LKML? Are there any distros interested?
Genuine question, what are the litations?
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.
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).
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.
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.
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.)
I thought Jessie had a good overview[0] of BPF
[0] https://blog.jessfraz.com/post/linux-observability-with-bpf/
He is an engineering god.
Disabling kernel module loading, or restricting it to signed modules shuts down many of the vectors without using out of tree code. There are many security switches that are generally left off in widely distributed kernels that provide deep protection when you don't need to support everyone's project and app.
For specific distributions like those listed this is fine, but those also generally aren't used in higher assurance environments either.
sysctl -w "kernel.modules_disabled=1"
Is there a place where these options are listed? Preferably with the pros/cons of enabling each option.
Good place to start: building your own kernel from source. I tried that once and was quite overwhelmed with the sheer number of knobs and features that are available.
While I do still want a centralized list of things to do/check for hardening a kernel, I don't think it will _ever_ be exhaustive. And some pros/cons would involve very _deeply_ complex behavior which would be difficult to determine whether or not the tradeoff is even relevant.
https://www.reddit.com/r/sysadmin/comments/d1ttzp/oracle_is_...
I remember it as Sun. But looking it up, Sun acquired it from something called Innotek GmbH.
I don't get the impression that Oracle is putting a lot of serious engineering effort on the old Sun products, aside from maintenance. Anyone keeping the lights on is probably unlikely to get offended by the thing from 2 layers of acquisition being called "crap".
Virtualbox represents exactly as much threat to your business as an OpenIndiana or FreeBSD server. Are you sure that a sysadmin is not using (CDDL licensed) ZFS?
Watch your licenses. Oracle Java JRE/JDK switched to a proprietary commmercial license (it's time to switch to openjre/openjdk including on the desktop. You're either out of date on patches or running oracle non-cddl code (prepare to bend over)
openjdk jre link: https://adoptopenjdk.net/installation.html?variant=openjdk11...
Affero GPL/AGPL is commercially toxic as well. Java iTextPdf is probably the most common thing.
(It is not especially clear to me what exact mitigations TFA describes; it seems to be glossy ad copy rather than technical documentation.)
I'm not sure I'd want "!!!" log lines going to the primary business log when only the suspicion of an attack exists.