[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 21 Jun 2020 15:10:01 +0200
From: Solar Designer <solar@...nwall.com>
To: lkrg-users@...ts.openwall.com
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.
Alexander
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.
