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.