Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 21 Jun 2020 17:53:48 +0200
From: Mikhail Morfikov <mmorfikov@...il.com>
To: lkrg-users@...ts.openwall.com
Subject: Re: rootkit detection

On 21/06/2020 15:10, Solar Designer wrote:
> 
> Here's an idea on how to avoid the inconsistency with other *_enforce
> settings: keep the lkrg.block_modules name, but shift the values to
> start at -1, so that the values 0 and 1 act similarly to how they do
> now (only adding the logging at 0).  Sounds good to you?

Yes, it can start with -1. There are some kernel parameters which hold "-1", so
it's not that strange to me.

> 
> OK, added this:
> 
>   Also relevant is the kernel's kernel.modules_disabled parameter, which fully
>   disables module loading until the system is rebooted.
> 
> Should we also mention that kernel.modules_disabled is potentially
> bypassable by other means without a kernel lockdown?  And is bypassable
> via vulnerabilities even then.  I didn't add that yet, because we're
> writing LKRG documentation and not a general kernel security guide.
> This is just a "see also" kind of reference.  Also, LKRG can catch some
> of those bypasses.
> 

Keep in mind that when lkrg.block_modules will be ready, it will be similar to 
kernel.modules_disabled , and if they share the same vulnerabilities, I think it's 
better to write some words just to warn people so they know that some issues exist.



Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.