Module Signatures Confussion

As part of general security tips for Linux I had thought I had understood that normally most modules were downloaded with signatures and that sometimes it was wise to check the ones that weren’t ‘signed’?

My understanding was that some like NVIDIA and othe more propriety modules were normal to not have signatures. The output command I found and thought I had understood what it was doing seems to output rather a lot of familiar looking packages to do with system things ip_tables, ext4 etc and v4l2loopback for the virtual OBS camera; but there seems to me to be a rather a lot of them. So either I somehow have the command wrong or perhaps I have missunderstood which packages are ‘normal’ to not have signatures or something? I’m sure there’s proberly some better vocabulary somewhere or something more that I’m only beginning to understand possibly?

Any clarrifications/help would be muchly appreciated.

for mod in $(lsmod | tail -n +2 | cut -d' ' -f1); do modinfo ${mod} | grep -q "signature" || echo; echo "no signature for module: ${mod}"

no signature for module: ip6t_REJECT, nf_reject_ipv6, xt_hl, ip6t_rt, nf_log_ipv4, nf_log_common, ipt_REJECT, nf_reject_ipv4, xt_LOG, xt_recent, xt_limit, ip6table_filter, ip6_tables, nf_conntrack_netbios_ns, nf_conntrack_broadcast, nf_nat_ftp, nf_conntrack_ftp, rndis_host, cdc_ether, usbnet, mii, xt_nat, xt_tcpudp, veth, udp_diag, tcp_diag, inet_diag, xt_conntrack, xt_MASQUERADE, nf_conntrack_netlink, xfrm_user, xfrm_algo, xt_addrtype, iptable_filter, iptable_nat, nf_nat, nf_conntrack, nf_defrag_ipv6, nf_defrag_ipv4, br_netfilter, bridge, stp, llc, overlay, hid_logitech_hidpp, joydev, input_leds, mousedev, hid_logitech_dj, uas, usb_storage, cfg80211, nfnetlink, rfkill, snd_usb_audio, uvcvideo, snd_usbmidi_lib, videobuf2_vmalloc, videobuf2_memops, snd_rawmidi, videobuf2_v4l2, videobuf2_common, snd_seq_device, hid_generic, usbhid, squashfs, hid, nls_iso8859_1, nls_cp437, vfat, fat, loop, ucsi_ccg, typec_ucsi, btrfs, typec, edac_mce_amd, nvidia_drm, snd_hda_codec_realtek, nvidia_modeset, kvm_amd, snd_hda_codec_generic, blake2b_generic, xor, wmi_bmof, ledtrig_audio, drm_kms_helper, kvm, snd_hda_codec_hdmi, cec, snd_hda_intel, rc_core, snd_intel_dspcfg, snd_hda_codec, irqbypass, drm, snd_hda_core, crct10dif_pclmul, crc32_pclmul, snd_hwdep, ghash_clmulni_intel, snd_pcm, agpgart, aesni_intel, syscopyarea, snd_timer, raid6_pq, sysfillrect, crypto_simd, ccp, cryptd, snd, glue_helper, nvidia, sp5100_tco, libcrc32c, rapl, sysimgblt, pcspkr, k10temp, r8168, rng_core, fb_sys_fops, i2c_nvidia_gpu, soundcore, i2c_piix4, wmi, acpi_cpufreq, evdev, mac_hid, gpio_amdpt, pinctrl_amd, v4l2loopback, videodev, mc, sg, fuse, crypto_user, ip_tables, x_tables, ext4, crc32c_generic, crc16, mbcache, jbd2, crc32c_intel, xhci_pci, xhci_hcd

The packages those modules belong to are/is the kernel itself - which is already signed as a whole.
The kernel modules are not downloaded separately.
They belong to and are part of the kernel package.

Ah okay. That’s good and makes sense. Is there any way of not outputting kernal modules alongside ‘unsigned’ moduels?

I have no idea what you mean.
you seem to go from the assumption that there are “unsigned modules” and “signed modules”
AFAIK that is just that: an assumption

Yeah, I was trying to understand it but I don’t think I understand why UnsignedKernelModules might be bad?

Referencing the script from CT I think there was ‘;’ in my code causing the problem ‘…|| echo; echo…’

Now it’s back to just outputing these:

A “UnsignedKernelModule” is not bad or insecure. It just means it has no signature. Since no distribution Kernel enforces a signature, it does not matter in any way. By default all mainline Kernel modules, that are build with the Kernel, are singed by an autogenerated key.

But sine the private key is lost all third party Kernel modules or modules build with dkms are not singed.

Interesting is it only, if you build your own kernel and use your own key. To improve security, you can use a setting that allow only singed modules to be loaded. And the public key needs to be part of the Kernels keyring. A Key can only added at Kernel build time. So no attacker can load own modules or can trick you in loading a malicious module.

Something I wrote on the old forum on this topic.