[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8452bbcd-8840-9b26-20c8-080540a8f9cf@gmail.com>
Date: Sun, 21 Jun 2020 11:26:35 +0200
From: Mikhail Morfikov <mmorfikov@...il.com>
To: lkrg-users@...ts.openwall.com
Subject: Re: rootkit detection
On 21/06/2020 00:23, Solar Designer wrote:
>
> FWIW, here's my tentative proposal from a few months ago for replacing
> lkrg.block_modules, which we ended up not doing yet:
>
> ---
> modules_enforce 0 no enforcement, 1 log only, 2 block loading, 3 block loading and unloading, 4 also lock this setting itself
> (lkrg.modules_enforce=4 will be same as kernel.modules_disabled=1, except it'd also have LKRG's logging)
> ---
>
> Do you like this?
Yes, this looks good to me.
> For now, we're going to document lkrg.block_modules as follows:
>
> ---
> - lkrg.block_modules (0)
> Whether or not to block further loading of kernel modules. Allowed values
> are 0 (no) and 1 (yes).
>
> This feature is meant primarily to prevent unintended user-triggered (or
> attacker-triggered) auto-loading of maybe-vulnerable modules provided in a
> distribution after all intended modules have already been loaded. This
> feature is not effective (nor is meant to be) against attackers who already
> have root privileges and try to load a module explicitly (they could simply
> flip this setting or even unload LKRG first).
> ---
>
I would also add here some info on the kernel.modules_disabled option, to point
users in the right direction when they look for a mechanism to completely lock
the module loading feature.
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.
