Hacker News Reader

Comment by JeremyNT | Hacker News Reader

Distro maintainers blacklisting specific functionality because they believe YAGNI is a pretty big ask. They just don't know who is using what. It's always possible for users to go back and tailor their builds for the stuff they actually want.

And... I remember the early days of Linux where I ran `make menuconfig` and selected exactly the functionality I wanted in my kernel. I'd... rather not end up back there.

That said a target for an easy win here is RHEL, which compiles a lot of modules into the kernel rather than leaving them as loadable modules, so the mitigation for e.g. copy fail was impossible. Maybe they could do with a few less of those?

View on HN

You can make precisely the same argument for network services. Who knows, maybe you need telnet and UUCP and NFS and ftpd running on your system?... why should the distro maintainer decide?

Well, because you probably don't, and it's a security risk, so no need to put millions at risk for the benefit of that one person who wants to tinker with packet radio or whatever. Similarly, it would be prudent for distros to not allow autoloading of modules that are extremely niche while giving a simple way to adjust the settings if you want to. God knows they have plenty of GUI configurators and config files already.

The thing is that we could simply split those modules into separate packages

No reason why you couldn’t just `dnf install -y kmod-rxrpc` if for whatever reason you need that.

Now I think about it, it's kinda weird if non-root users can cause kernel modules to get loaded, without any hardware changes having happened.

If the kernel modules for esp4, esp6 and rxrpc aren't loaded - how is it that a non-root attacker can cause them to get loaded?

It seems that this is allowed as part of a dependency chain...

>Distro maintainers blacklisting specific functionality because they believe YAGNI is a pretty big ask

We have forgotten what a distro is, and its modern corruption of the concept is now taken as the definition.

Distributions weren't meant to be competing generic universal bundles of userspace tools in addition to the kernel.

Don't disagree, but there are eBPF mitigations that work as alternatives to unloading kernel modules.

Can you elaborate on that?

Have a look at https://github.com/atgreen/rhel-block-copyfail

Thanks!

From the sound of it, the same mitigations for Copy Fail 1 are also effective here.

No, they are different. I just bundled them together for convenience in this POC. The only real thing in common is that they both use eBPF.

Got it, thanks!

I was aware of commercial antivirus vendors (Crowdstrike) doing something like this, but this is the first I've seen it published by somebody in the open!

Have you considered writing up a blog post and submitting this to HN?

Reply on news.ycombinator.com