A clarification on the correct usage of files in modprobe.d to block loading of modules in Linux Kernel

[Archie1]

In the the directory

This is being asked because of the recent linux vulnerability dirty frag. Now one of the methods to mitigate this is to switch off IPv4 and IPv6 ESP along with the RxRPC protocol used in the Andrew File System (AFS). According to the recommendation it is required that a .conf file is created in the directory /etc/modprobe.d/ with the following content

install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false

Now I was under the impression that to block modules being loaded into Linux Kernel we have to use something like this

install hfs /bin/true
install hfsplus /bin/true

This will block the Mac OSX HFS and HFS+ filesystem modules. i.e. use /bin/true instead of /bin/false

Which one of these is correct?

Also another file can be created in the /etc/modprobe.d/ directory which has the following contents. This will also block the modules.

blacklist hfs
blacklist hfsplus

So in similar vien can we also use the following in a .conf file too to block IPv4 and IPv6 IPsec?

blacklist esp4
blacklist esp6
blacklist rxrpc

[Bink]

Was worth checking, so thank you for asking that:

install

There is a workaround for the behaviour described in the #alias and #blacklist notes. The install configuration command instructs modprobe to run a custom command instead of inserting the module in the kernel as normal, so you can simulate the successful module loading with:

/etc/modprobe.d/blacklist.conf

install *module_name* /bin/true

You can force the module to always fail loading with /bin/false: this will effectively prevent the module—and any other that depends on it—from loading by any means, and a log error message may be produced.

install - Kernel module - ArchWiki

So based on that, this will disable these modules:

@Archie1

install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false

[Archie1]

Okay so from what I get if
install *module_name* /bin/true
is used then instead of the *module_name* a /bin/true will be loaded. Since this is /bin/true it will not be logged into the syslog or systemd-log as a failure, just that the module will not load.

On the other hand if
install *module_name* /bin/false
is used then also the module will not be loaded but a error log entry will be created into the syslog or systemd-log.

So in both the cases the modules does not load in the kernel but in case of usage of /bin/false a error log entry is created which does not happen in the case of usage of /bin/true. Is this correct? Is there something more to this?

And finally about using the
blacklist *module_name*
in a .conf file. How does that work? And what is its impact? Will it be of any use?

What if we have both, i.e. blacklist as well as install *module_name* /bin/true?

[cactux]

The modules don’t seem to be loaded to begin with so a blacklist would make no difference.

Check, for example: lsmod | grep esp4

[mbod]

@Bink

So based on that, this will disable these modules:

@Archie1

install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false

But with /bin/true the modules are disabled as well. Both, /bin/false and /bin/true achieve the same thing.

See step 3 in this document:

How do I prevent a kernel module from loading automatically? - Red Hat...

With /bin/true modprobe believes that the module was loaded successfully. With /bin/false modprobe will get an error loading the module and will pass that error on to the calling program.

If you want to prevent error log spam you should use /bin/true:

Modprobe is better disabled by using /bin/true (not /bin/false)

[Archie1]

@cactux

The modules don’t seem to be loaded to begin with so a blacklist would make no difference.

Check, for example: lsmod | grep esp4

So I ran the command and this is the output. Please note that I have not created a /etc/modprobe.d/blacklist.conf nor /etc/modprobe.d/dirtyfrag.conf with blocking of modules esp4 and esp6

$  lsmod | grep esp4
$
$ lsmod | grep esp4
$
$  lsmod | grep afs
$
$  lsmod | grep ext
(standard input):78:snd_hda_ext_core       36864  7 snd_sof_intel_hda_sdw_bpt,snd_soc_avs,snd_soc_hda_codec,snd_sof_intel_hda_common,snd_soc_hdac_hda,snd_sof_intel_hda_mlink,snd_sof_intel_hda
(standard input):83:snd_hda_core          147456  13 snd_hda_codec_generic,snd_soc_avs,snd_hda_codec_hdmi,snd_soc_hda_codec,snd_hda_intel,snd_hda_ext_core,snd_hda_codec,snd_sof_intel_hda_common,snd_hda_codec_realtek_lib,snd_soc_hdac_hda,snd_hda_codec_alc269,snd_sof_intel_hda,snd_hda_codec_intelhdmi

The command is run by a standard user, without root privileges. So no su - was used nor was sudo used.

Based on the output of the lsmod for both esp4 and esp6 does that mean these modules were not loaded by the Linux Kernel.
My existing Linux kernel is

$  uname -sro
Linux 7.0.3-arch1-2 GNU/Linux

[cactux]

From man lsmod

DESCRIPTION
lsmod is a trivial program which nicely formats the contents of the /proc/modules, showing what kernel modules are currently loaded.

So if

@Archie1

lsmod | grep esp4

doesn’t output anything, that means the module is not loaded in the kernel.

[Bink]

That’s really good clarification, thank you

[Archie1]

@mbod

With /bin/true modprobe believes that the module was loaded successfully. With /bin/false modprobe will get an error loading the module and will pass that error on to the calling program.

If you want to prevent error log spam you should use /bin/true:

https://github.com/ComplianceAsCode/content/issues/539

Thanks @mbod that cleared up a lot. If you do not mind me picking your brains for a few follow up questions.

Firstly from what I gather using /bin/false might help in troubleshooting as it will be logged into the syslog or systemd-log that the module loading failed. So in that way it might be useful while troubleshooting. But on the other hand if a malicious actor were to gain access to the system, either remotely or physically means not relevant right now, then it would help that the syslog/systemd-log not have an entry showing that the module loading failed. It will make malicious actors work harder. Is this logical and correct?

Secondly the log entry will be created only once right? While the system is booting or rebooting. Post that in normal working there will not be any log entry unless a module is loaded explicitly from the terminal. Is this correct too?

[Archie1]

@cactux

So if

@Archie1

lsmod | grep esp4

doesn’t output anything, that means the module is not loaded in the kernel.

Since esp4 and esp6 are not loaded does that mean the computer running Arch Linux Kernel 7.0.3-arch1-2 G is safe from dirty frag ? Offcourse the module esp4 could be loaded via a terminal command.

[mbod]

@Archie1

It will make malicious actors work harder. Is this logical and correct?

No. The mechanism with “install *module_name* /bin/false” is only valid for the modprobe command. But the modul can still be loaded with the insmod command.

E.g.

I have: install algif_aead /bin/false

I try modprobe and I get:

# modprobe algif_aead

modprobe: ERROR: Error running install command ‘/bin/false’ for module algif_aead: retcode 1
modprobe: ERROR: could not insert ‘algif_aead’: Invalid argument

But I can load the module with insmod:

# insmod /lib/modules/6.18.27-273.1-linux618-tkg-x86-64-v3/kernel/crypto/algif_aead.ko.zst


# lsmod | grep algif                                                        
algif_aead             12288  0

@Archie1

Secondly the log entry will be created only once right?

This is not predictable. It depends on the calling program. If a program tries to load the modul only once, there will be only one log entry. But if it tries to load the modul multiple times, e.g. every minute, you will see multiple log entries.

[cactux]

@Archie1

@cactux

So if

@Archie1

lsmod | grep esp4

doesn’t output anything, that means the module is not loaded in the kernel.

Since esp4 and esp6 are not loaded does that mean the computer running Arch Linux Kernel 7.0.3-arch1-2 G is safe from dirty frag ?

I couldn’t answer that since it is above my pay grade. The absence of output from lsmod only says that the modules are not currently loaded into the kernel. They do seem to exist on the disk though:

find /lib/modules/$(uname -r) -name "*.ko.zst" |grep -E "esp4|esp6|rxrpc"

Perhaps someone more knowledgeable could provide more insight.

[Archie1]

@cactux

@Archie1

@cactux

So if

@Archie1

lsmod | grep esp4

doesn’t output anything, that means the module is not loaded in the kernel.

Since esp4 and esp6 are not loaded does that mean the computer running Arch Linux Kernel 7.0.3-arch1-2 G is safe from dirty frag ?

I couldn’t answer that since it is above my pay grade. The absence of output from lsmod only says that the modules are not currently loaded into the kernel. They do seem to exist on the disk though:

find /lib/modules/$(uname -r) -name "*.ko.zst" |grep -E "esp4|esp6|rxrpc"

Perhaps someone more knowledgeable could provide more insight.

So found the answer. No if the modules are not loaded currently then they can be loaded. What is required is setting the values and a reboot.
Source 1: https://github.com/V4bel/dirtyfrag/issues/1

Correct - i can confirm that, exploited hosts / tests the mitigation (removing/disabling esp4 esp6 and rxrpc) do need a reboot.

Just removing the kernel modules without rebooting does not affect already exploited machines (i’m guessing cause of how the exploit works, with overwriting the page-cache for /bin/su).

Source 2: What @mbod had just posted earlier in this thread.