Linux's modprobe Adds The Ability To Load A Module From Anywhere On The File-System

[Inopia]

TIL insmod existed 😅

I was gonna rave about how this is so needed addition when dealing with ostree+secure boot+3rd party kernel modules but turns out I was just doing things the hard way.

You never stop learning 😇

[oiaohm]

Do I think we should not be allowed to do this, but it does add potential to increase the attack surface a bit.

This is one of these problems. insmod for ever has allowed loading modules from where ever.

https://www.geeksforgeeks.org/insmod-command-in-linux-with-examples/

The difference between modprobe and insmod has been that modprobe will autoload module dependencies. Has it been possible to script write up a fully functional modprobe using insmod the answer is yes.

The reality if modprobe loading modules anywhere on the file system is a problem then insmod should also have this feature removed.

There is a use case for this change immutable systems so that the core image does not need to be modified to use third party drivers or optional drivers.

andresdju says about a buggy script. User writing own hacked up version of modprobe using insmod is way more likely to have major screw ups than this change.

I really would like modprobe to have this functionality for the different use cases but I would also like to have something like PATH that we have for commands that list currently approved locations for modules and this limitation apply to both modprobe and insmod.

Locked to only 1 directory has had its own fair share limitations. With no restriction has its on fair share of problems. In my eyes the answer is in the middle.

Yes the module path options could be locked in the kernel command line .

Basically I agree the security side of this does need to be looked at. But we need to be truthful parties have for years been doing the same thing with own hacked up versions of modprobe using insmod and this without restriction has not be security sound either.

[stormcrow]

Heck OpenBSD removes loadable kernel modules entierely and here Linux is saying hey if you are root you can load this snazzy new module from your downloads directory! Seems like an easy way to shoot yourself in the foot for mid level users or users coming from windows world used to installing drivers from downloads.

No. OpenBSD has loadable kernel modules turned off by default with a monolithic kernel build. The feature is not removed entirely. There's a big difference. It's also not what "Linux is saying". Not even remotely. You still need elevated privileges to load kernel modules unless some fool disables that barrier or equally stupidly defines a weak or non-existent root password. No OS on the planet, not even OpenBSD or MacOS, will fully protect people from their own stupidity. See my above posting.

I also don't believe for a moment OpenBSD, which is literally just another Unix system with the same built in conceptual weaknesses, will stand up to wholesale scrutiny from researchers and attackers just like Linux didn't once it started getting attention. I also don't believe that scrutiny is likely, as OpenBSD's overall performance is pretty abysmal, and most people will look at that (and a lack of some critical modern features like TRIM - and yes I know exactly why it's not in OpenBSD, and I also know the reasoning is bunk) and pass it up. Security research tends to go with the money. There's no real payout except street-cred for breaking OpenBSD. Not that people don't still do it. There's the occasional article that makes it into 2600 about finding vulnerabilities in OpenBSD (and let's not forget about the errata listing).

andresdju I believe you're overthinking it. There's no behavior change here that didn't already exist. A "buggy script" still requires privilege elevation, intentional or otherwise. If that were written naively by the administrator of the system, that's pretty much on them. It's impossible to remove all foot guns from a complex system this old. Someone somewhere is going to find one and shoot themselves in the foot. That doesn't mean we should completely remove all dangerous artifacts just because someone naively used it without understanding what they were doing. It doesn't even take a "buggy script" if this is an intentional attack, nor would it matter which directory the module originally downloaded to. It's trivial once someone has root to move it to the appropriate directories and rebuild the initramfs (which doesn't necessarily require either insmod nor modprobe if a person is willing to wait for a reboot).

Like I said, once someone gains root on Linux (or OpenBSD) then not even the various mitigations built into Linux (or OpenBSD) will slow them down for very long. That's the nature of Unix and the Unix security model that not even capabilities based security frameworks can fully ameliorate. It's built into the "soul" of Unix-like OSes. This is why root and it's "god mode" has to be protected so fiercely and why new security paradigms not based on 60 year old OSes that originally ignored security considerations (or circumvented them on purpose like NT) is needed (like CHERI - which requires new hardware designs to fully utilize because the underlying hardware is part of the problem).

[Weasel]

Wow once again an absolute great feature and security asshats polluting everything with their hysteria, it's the reason Crapland will forever be a toy too.

modprove requires privileges to load the module. If you are root you have full control over the fucking filesystem, including placing your fucking module ANYWHERE, why the fuck does it matter?

Fantastic ability for convenience. I'm so sick of the word "security".

[oiaohm]

modprove requires privileges to load the module. If you are root you have full control over the fucking filesystem, including placing your fucking module ANYWHERE, why the fuck does it matter?

Not that straight forwards. modprobe can be auto run many different ways. You insert device modprobe could be auto run as part of udev to active the device. udev might have a buggy configuration.

So the user may not have root permissions themselves to perform some action that causes modprobe to run.

For users not needing to load kernel modules from where every being able to limit the paths limit the screw ups that auto parts like udev can do.

The security asshats are not wrong here. When you step back and look at the big picture generally enabling modules to be loaded from where ever may be path to o my god no due to allowing bugs to happen that would not otherwise be possible. Also being locked to a single path is problem for particular use cases.

Questions always with security

1) is does every user need this feature? if yes stop here security permissions on this is just going to be a pain in but..
2) then what percentage of users need this feature?
3) how deal breaking is it for users who need this feature?

This case 1 is no not every user need this feature. 2 is over 90% don't need this and have been functioning perfectly with the restriction in place not having a problem. 3 a percentage that do need it this is deal breaking particularly when you think read only file system and you need to load driver from a user directory for some reason. So this need permissions/restrictions of some form.

Yes insmod really should have had a permission limitation to prevent user using that stuffing up badly. There have been historic security issues with insmod being used in udev result in user insert device driver loaded from random home directory. The reason why modprobe has it current restriction has basically been forgot 2 decades latter.

Yes it the old don't learn from history problem we are doomed to repeat it. I suspect we are going to see another stack of issues with modprobe exactly the same as the issues we had with early Linux distributions and insmod being used automatically then finally maybe the security features that should have always existed on module loading get added..

[AlanTuring69]

Wow once again an absolute great feature and security asshats polluting everything with their hysteria, it's the reason Crapland will forever be a toy too.

modprove requires privileges to load the module. If you are root you have full control over the fucking filesystem, including placing your fucking module ANYWHERE, why the fuck does it matter?

Fantastic ability for convenience. I'm so sick of the word "security".

Clowns like you are the reason hospitals get hit by ransomware. Security engineers are the highest on the engineering totem pole for a reason.

[Weasel]

Clowns like you are the reason hospitals get hit by ransomware. Security engineers are the highest on the engineering totem pole for a reason.

Actually clowns like YOU are the reason they get hit, because you have 0 fucking clue how it works and think you're "safe" LMFAO.

I bolded that part for a reason, wanna take up on it and let's see your clown logic for it? I want a good laugh.

[oiaohm]

Actually clowns like YOU are the reason they get hit, because you have 0 fucking clue how it works and think you're "safe" LMFAO.

I bolded that part for a reason, wanna take up on it and let's see your clown logic for it? I want a good laugh.

You are in the same place here. insmod having a feature and modprobe not having matching feature that a clue that there was a problem in the past.

Yes we have a failure to learn from history here. Question if it going to come back and bite badly. The historic examples really do say that the means to load kernel modules from anywhere should have option to turn that off for users who don't need it.

[Weasel]

You are in the same place here. insmod having a feature and modprobe not having matching feature that a clue that there was a problem in the past.

Yes we have a failure to learn from history here. Question if it going to come back and bite badly. The historic examples really do say that the means to load kernel modules from anywhere should have option to turn that off for users who don't need it.

There is absolutely no need to turn it off. Not one. You can't simply type an absolute path (or relative path) by mistake and load malware.

And if you have root, which you need to load the module in the first place, you could just as well copy it anywhere you want before loading or remove your entire root or do anything you want.

[oiaohm]

There is absolutely no need to turn it off. Not one. You can't simply type an absolute path (or relative path) by mistake and load malware.
.

No the history of why insmod has it and modprobe had it removed is with shell autocomplete its really simple to do an absolute path and people did that mistake back in the day when insmod was the dominate way of loading drivers.

When you do ./something that is converted to a absolute path by the shell.

And if you have root, which you need to load the module in the first place, you could just as well copy it anywhere you want before loading or remove your entire root or do anything you want.

This is missing something.

https://cateee.net/lkddb/web-lkddb/MODVERSIONS.html

The history system break is linked to MODVERSIONS feature. User browsing and the kernel module storage location and by mistake do absolute path in form of ./ or equal so loading kernel module for the wrong kernel then doing a bug report for having a issue that X kernel does not have at all because they loaded the wrong driver.

This is the same problem why rm -rf has --no-preserve-root. Basically to prevent person from shooting self in foot unless they intentionally mean to. If you done a copy into the module directory that proof you have wanted to intentionally shoot self in foot. If you have been using insmod when all documentation says use modprobe you have wanted to intentionally shoot self in foot up to now.

The question is now are users still dumb/smart enough to screw up with the new version of modprobe as they use to when insmod was the default method of loading modules. Normally humans don't get smarter maybe the general user has got dumb enough that they would never use modprobe.

The history says this feature should be off by default with a on flag if we are learning from history from the time insmod was the only way to load kernel modules. The bet is that is no longer right but we will find out when the bugs come in if this is not changed to include this feature.

Yes this is a problem from over 25 years ago. Long enough that people like you Weasel most likely never saw it.