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 15:10:01 +0200
From: Solar Designer <>
Subject: Re: rootkit detection

On Sun, Jun 21, 2020 at 11:26:35AM +0200, Mikhail Morfikov wrote:
> 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.

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?

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

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.


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.