[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5f1402a8-8cde-707f-3a9f-ee339a51ed44@gmail.com>
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.
