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.