Slashdot Mirror

← Back to Stories (view on slashdot.org)

LKRG: A Loadable Linux Kernel Module for Runtime Integrity Checking (bleepingcomputer.com)

Posted by EditorDavid on from the monitoring-with-modules dept.

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.

17 of 36 comments (clear)

  1. Next project: by fahrbot-bot · · Score: 3, Funny

    A loadable Linux kernel module to check the run-time integrity of LKRG. It will be modules all the way down from there ...

    --
    It must have been something you assimilated. . . .
  2. Re:Like WordPress? by viperidaenz · · Score: 1

    Are the vulnerabilities free or paid?
    https://firstsiteguide.com/too...

  3. Am I the only one by Mister+Liberty · · Score: 2

    that doesn't like their 'business' model, the 'whatever Pro' thingy?

    1. Re:Am I the only one by EndlessNameless · · Score: 1

      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.

      --

      ---
      According to the latest ruleset, this post should be modded as Vorpal Flamebait +5.
  4. Defend as a late loaded by manu0601 · · Score: 1

    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.

    1. Re:Defend as a late loaded by Z00L00K · · Score: 1

      Like if you run the OS in a virtual environment - how can you trust the virtualization engine to not be compromised? Classic Blue Pill attack.

      --
      If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
  5. Use case? by Anonymous Coward · · 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?

    1. Re:Use case? by Anonymous Coward · · 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.

  6. What we really need is stabilized isolation by Anonymous Coward · · 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.

    1. Re: What we really need is stabilized isolation by jouassou · · Score: 1

      It seems like Subgraph OS is on the right track. They're also aiming for a sandboxed Linux setup, but they explicitly name usability as one of their goals, and seem to be integrating their sandbox features with the GUI. It'll be interesting to see how it develops.

  7. Tripwire, anyone? by xxxLCxxx · · Score: 1

    Has anyone seen something like 'Tripwire' making it to a standard distro? That could actually be useful and it would be relatively easy to implement. Therefore, I'm wondering why nobody seems to bother?

    1. Re:Tripwire, anyone? by xxxLCxxx · · Score: 1

      Lovely, but (mostly) useless. This is only interesting for bigger companies, if you have to do your own checksumming.
      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).

  8. good & bad? by sad_ · · Score: 1

    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?

    --
    On a long enough timeline, the survival rate for everyone drops to zero.
    1. Re:good & bad? by solardiz · · Score: 1

      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 yet unknown vulnerabilities where LKRG, as long as it's relatively unpopular, will likely just happen to defeat the usual/straightforward exploits for them. That said, we do in fact only recommend use of LKRG for systems where you expect not to be up-to-date with all patches anyway, and ask that admins of better maintained systems think twice before deciding on possibly using LKRG.

  9. Just fix the kernel by plsuh · · Score: 1

    FFS, what on earth is this good for? Just fix the damn vulnerability in the kernel and be done with it.

  10. Re: Known vulnerabilities by solardiz · · Score: 3, 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.

    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.

  11. Re:Useless + new attack vector by solardiz · · Score: 1

    20 years ago I used to build Linux 2.0.x without module support, and this sort of 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 (in the same Bitbucket repo, feel free to explore), which implements what I call (in e-mails with Adam) BSD securelevel on steroids (oh and yes, I used securelevel 20 years ago too; gave up since), and which I find suitable only for a minority of users (sysadmins) who are able to configure that thing reasonably. Of course, it deals with further module (un)loading, and other "legitimate" ways that root could backdoor the kernel.

    LKRG "main" as currently announced is for easier reasonable use on typical systems. It doesn't protect the kernel from root (authorized root, or root obtained via e.g. userspace exploits or, unfortunately, via a subset of kernel exploits that will bypass LKRG), but it detects some kernel vulnerability exploits (no, not only for known vulnerabilities - that's an error in the BleepingComputer & Slashdot story) and protects the kernel from those (as well as from other unauthorized changes, such as Rowhammer bitflips).

    Your reference to April fools is spot on. This is our most controversial project ever (as the very first sentence of our announcement says), and on January 29 when we made the announcement I happened to say in a chat with Adam: "i wish it were closer to April 1, but that would have been too long a wait ;-)"

    We're not delusional, and we try to do our best not to mislead the prospective users of LKRG (see also my other comments here, and the original announcement).