LKRG: A Loadable Linux Kernel Module for Runtime Integrity Checking (bleepingcomputer.com) 36
An anonymous reader quotes BleepingComputer:
Members of the open source community are working on a new security-focused project for the Linux kernel. Named Linux Kernel Runtime Guard (LKRG), this is a loadable kernel module that will perform runtime integrity checking of the Linux kernel. Its purpose is to detect exploitation attempts for known security vulnerabilities against the Linux kernel and attempt to block attacks. LKRG will also detect privilege escalation for running processes, and kill the running process before the exploit code runs.
Since the project is in such early development, current versions of LKRG will only report kernel integrity violations via kernel messages, but a full exploit mitigation system will be deployed as the system matures... While LKRG will remain an open source project, LKRG maintainers also have plans for an LKRG Pro version that will include distro-specific LKRG builds and support for the detection of specific exploits, such as container escapes. The team plans to use the funds from LKRG Pro to fund the rest of the project.
The first public version of LKRG -- LKRG v0.0 -- is now live and available for download on this page. A wiki is also available here, and a Patreon page for supporting the project has also been set up. LKRG kernel modules are currently available for main Linux distros such as RHEL7, OpenVZ 7, Virtuozzo 7, and Ubuntu 16.04 to latest mainlines.
Since the project is in such early development, current versions of LKRG will only report kernel integrity violations via kernel messages, but a full exploit mitigation system will be deployed as the system matures... While LKRG will remain an open source project, LKRG maintainers also have plans for an LKRG Pro version that will include distro-specific LKRG builds and support for the detection of specific exploits, such as container escapes. The team plans to use the funds from LKRG Pro to fund the rest of the project.
The first public version of LKRG -- LKRG v0.0 -- is now live and available for download on this page. A wiki is also available here, and a Patreon page for supporting the project has also been set up. LKRG kernel modules are currently available for main Linux distros such as RHEL7, OpenVZ 7, Virtuozzo 7, and Ubuntu 16.04 to latest mainlines.
What we really need is stabilized isolation (Score:1)
What would be nice is if someone could figure out how to roll out SELinux or Qubes/Xen Hypervisor protections in a way that works for actual, normal m enterprise and desktop use without bricking large portions of the OS.
Re: (Score:2)
Next project: (Score:4, Funny)
Re: (Score:2)
Are the vulnerabilities free or paid?
https://firstsiteguide.com/too... [firstsiteguide.com]
Re: (Score:2)
20 years ago I used to build Linux 2.0.x without module support, and this sort of [phrack.org] made sense. It still could make a little bit of sense, but the reality is that current kernels are huge (meaning an increase in vulnerability count, too) and most systems are running distro-provided kernels built with module support anyway.
If you want to protect the kernel from root, you need something other than current LKRG "main" branch. Something like Adam's in my opinion even more controversial LKRG "experimental" branch
Am I the only one (Score:3)
Re: (Score:2)
They could make the Pro version free for personal use. Or reduced cost. A lot of developers/companies only charge businesses and government for their products.
If they decide to charge for personal use, then we'll have to look at the software to see if the free version is worthwhile on its own merits.
I don't begrudge them a revenue stream. If they're doing this more as a job than a hobby, good for them.
Defend as a late loaded (Score:2)
I thought it was settled that you cannot defend against an attacker that loaded before your code, possibly with higher privileges.
Hence you have a hard time dealing with new threat, that you do not detect once, and that is there before you load an updated module.
Re: (Score:2)
Like if you run the OS in a virtual environment - how can you trust the virtualization engine to not be compromised? Classic Blue Pill [wikipedia.org] attack.
Use case? (Score:1)
Ok this is probably a stupid question but I don't understand why this is useful.
If they're going to protect against known exploits then not just fix the exploit?
Were there problems getting the fix accepted in the mainstream kernel, or is this for honeypots to watch exploit attempts? Who wants this and why?
Re: (Score:1)
From TFS:
Peslyak says LKRG is most suited for Linux machines that can't be rebooted right in the aftermath of a security flaw to patch the kernel. LKRG allows owners to continue to run the machine with a security measure in place until patches for critical vulnerabilities can be tested and deployed during planned maintenance windows.
Re: Known vulnerabilities (Score:4, Insightful)
Actually, it's one of several errors in BleepingComputer's rewording of our original announcement. I am grateful to them for reporting on our work and I understand that journalists have to reword for original content and copyright reasons, but this inevitably leads to errors, and we'd be happier with people reading our original announcement [openwall.com].
No, LKRG is not just for known vulnerabilities. It is both for currently known and for future vulnerabilities that are yet unknown, but it's limited in the vulnerability categories and exploitation/persistence methods that it will catch.
In the original announcement, we acknowledge that LKRG is highly controversial, can be bypassed, is limited in what it can do, and isn't always a good idea to use. We say that it provides merely the controversial notion of security through diversity (as long as LKRG, or a given branch of it, is not very popular), much like running an uncommon OS kernel would, but without the usual drawbacks of actually running an uncommon OS.
Indeed, that's not perfect security, unlike fixing all security vulnerabilities would be - but realistically the Linux kernel is monolithic and so huge (and growing) and distros enable so much of its functionality by default (including with module auto-loading, ouch) that in practice it will always have plenty of vulnerabilities anyway, and a clutch like LKRG may fit some Linux installs just right, unfortunately. Not make them "secure" - just reduce the percentage of successful compromises in the real world.
We try to give some guidelines on where LKRG may be beneficial (on systems that are not well-maintained or not promptly rebooted into new kernels anyway) and where it's probably not (on otherwise hardened and/or well-maintained and promptly updated/rebooted/live-patched systems). We're not delusional, and we try to do our best not to mislead the prospective users of LKRG.
Tripwire, anyone? (Score:1)
Re: (Score:1)
If the distros would implement it, however, this would be far more practical. You could even boot from a distro-CD/DVD to check if your system is clean (signed checksum-db).
good & bad? (Score:2)
Interesting project, however now i wonder how many people will opt for using this module (which could be easily activated & used) instead of properly patching their systems.
The module only detects known vulnerabilities, if you are running a tight ship, you should be all patched and what use does this have then?
Re: (Score:2)
Interesting project, however now i wonder how many people will opt for using this module (which could be easily activated & used) instead of properly patching their systems.
Yes, we share this concern. What matters even more: will fewer or more systems get compromised as a result? Or even: will the cumulative damage of those compromises decrease or increase? We have no answers to these, yet we feel that an imperfect security measure like this may have its reasonable uses on some systems.
The module only detects known vulnerabilities, if you are running a tight ship, you should be all patched and what use does this have then?
"Only detects known vulnerabilities" is an error in the BleepingComputer article, but regardless - yes, ideally you should be all patched, but realistically you might not be and there might be y
Just fix the kernel (Score:2)
FFS, what on earth is this good for? Just fix the damn vulnerability in the kernel and be done with it.