[Bug 295485] need a way to block zfs.ko from being autoloaded by tools like puppet and facter (FatGID Vuln / CVE-2026-45250)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295485

--- Comment #22 from Dan Mahoney <[email protected]> ---
*sigh*

I've filed this as an upstream issue with OpenZFS, and have referenced this
issue as well as 270789 (which occurred with the btop program doing similar
nonsense).  I honestly think btop is more egregious -- it's a diagnostic
program that goes off and changes the state of the system you're trying to
diagnose, in ways you don't expect.

https://github.com/openzfs/zfs/issues/18593

OpenZFS has about 1500 open issues.  I'm not optimistic it will get fixed
there.

I stand by my statement: a kernel module being loaded when you haven't
explicitly asked for it to, and have no expectation that you're using the thing
supplies breaks POLA.  If you're sitting at the system console, you might see
some dmesg output, but it's otherwise invisible.  And yeah, normally, it's just
another loaded module (even if it's a fat one, I'd be much more concerned about
this behavior on a 2G-Ram RPI).

My honest hope would be for a sysctl that basically stopped kernel module
loading once you were multi-user, sort of a "securelevels lite" that didn't
make you need to reboot the system into a lower securelevel to run updates (we
run a lot of dells, they boot slow).

Oliver's suggestion of using the kldconfig to change the authorized loader path
and then to push symlinks of whitelisted modules is an interesting one and we'd
need to test it to make sure, e.g. that the right symlinks would behave
correctly on a system update (i.e. where one had booted into a new kernel, or
in the event of a rollback where one was running out of kernel.old), but I
think it has merit.

We now return you to your regularly scheduled "which friggin exploit will an
LLM dream up for us this week because someone wants to do a DEFCON talk".

-Dan

-- 
You are receiving this mail because:
You are the assignee for the bug.