Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 21 Jun 2020 11:26:35 +0200
From: Mikhail Morfikov <>
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.