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.

36 comments

  1. but yeah... by Anonymous Coward · · Score: 0

    ... will it check the Intel Management Engine?

  2. 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. . . .
  3. Like WordPress? by Anonymous Coward · · Score: 0

    I see lot of WordPress themes and plugins authors provide free version with limited functionalities and paid pro version with additional functionalities.

    1. Re:Like WordPress? by viperidaenz · · Score: 1

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

    2. Re:Like WordPress? by Anonymous Coward · · Score: 0

      Wordpress.

      What a petri dish.

  4. Useless + new attack vector by Anonymous Coward · · Score: 0

    So let me get this straight:

    You need to enable module loading, aka an attack vector for injecting code straight into the kernel,

    wich is done *by* the kernel, meaning that if it is infected, it has full control over altering the module to avoid detection,

    so it "can detect" if the kernel has been exploited?

    Is this an NSA trap or an April fools joke?

    1. Re:Useless + new attack vector by Anonymous Coward · · Score: 0

      Loadable kernel modules were always a catastrophe waiting to happen. All that shit needs to load into and stay in userland. There is never, ever any reason for a loadable kernel module other than sheer laziness, incontinence, or both.

    2. 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).

    3. Re:Useless + new attack vector by Anonymous Coward · · Score: 0

      Found the arrogant idiot who has no clue what the fuck he's talking about.

      Welcome to /.

  5. 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 Anonymous Coward · · Score: 0

      Probably not.

      Well, there is no-one forcing either version of the program down your throat so I don't really see what the problem is.
      There are plenty of programs I don't like and therefore do not use.

    2. 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.
  6. 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.
  7. 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.

    2. Re:Use case? by Anonymous Coward · · Score: 0

      Who wants this and why?

      That isn't how it works.

      They will target the top of the company with their marketing, either directly or through business magazines and say something like "you can't afford to not have it".
      Then the pro version will be bought and installed regardless of what anyone who understands what the software does thinks.

  8. Sounds like antivirus by Anonymous Coward · · Score: 0

    Mostly pointless

  9. Known vulnerabilities by Anonymous Coward · · Score: 0

    "Its purpose is to detect exploitation attempts for known security vulnerabilities against the Linux kernel and attempt to block attacks."

    If the vulnerabilities are known, why not just patch them instead of adding this new module and take a associated (small) performance hit?
    (I'm not a kernel hacker, but on the face of it this seems odd to me)

    1. Re: Known vulnerabilities by Anonymous Coward · · Score: 0

      Well, even though the vulnerability is known, the user might not know it. Also, it might be some thing loaded after.

    2. 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.

  10. 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.

    2. Re: What we really need is stabilized isolation by Anonymous Coward · · Score: 0

      I like the idea of Subgraph, but it has been in development for four years and is still in alpha. I fear that the progress has been stalled.

  11. 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 Anonymous Coward · · Score: 0

      Wasn't tripwire, i.e., an inefficient checksum based approach to security, made largely obsolete by file monitors.

    2. Re:Tripwire, anyone? by Anonymous Coward · · Score: 0

      Like Aide and Tiger ?

    3. 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).

  12. How does that make it any better? by Anonymous Coward · · Score: 0

    How does it matter, whether an integral part of the system is part of the kernel or not? It will always be a gatekeeper, being able to ruin every process' day.
    In fact, in user space, it itself will just be vulnerable, instead of being the source of vulnerabilities, like when inside the kernel.

    What we actually need, is compartmentalization. Per (verified) developer as well as per role. So a separate environment for each service, and a firewall / RBAC-like system controlling the gate APIs.
    The problem is: We've tried that. With microkernels. And even without the firewall, it turned out to be unacceptably slow.
    Maybe, like with garbage collectors, it's time to bite the bullet, and just accept the resource usage being worth it. I'll always feel uneasy about it though.

  13. But that is the intention! by Anonymous Coward · · Score: 0

    It's not like you can't tell from a thousand miles away, what the logical end state will be, and that it will entails some kind of forcing.
    At least in every single damn case I have experienced since the earliest days of playing shareware games as a child.

  14. Assuming, of course, the infection hasn't already by Anonymous Coward · · Score: 0

    ...happened.

  15. 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.

  16. Main Linux Distros? by Anonymous Coward · · Score: 0

    OpenVZ 7? , Virtuozzo 7?

    But I guess four places to load malcode into your kernel is better than two.

  17. 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.