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

[kylew77]

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).

Thanks for the reply. Are you saying that Access Control Lists would be better than the standard user, group, others? I personally hope to do a project if I ever go back to school exploring OpenBSD's security. I agree once you gain root access the system can be compromised in any way possible. I was just referring to that social engineering can work easily if they can convince the user to invoke sudo on a module in the downloads directory. That's all.

[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".

"sudo -s" ever heard of it? The very first command literally everyone worth any degree of engineering or security competency runs before they execute any command because Lunix permissions are a flustercuck? Would love to hear your excuse as to why root should be this special user that can modify the kernel on-demand when root is what almost all demons run under?

Lunix needs to get away from the headless-by-default scheme and rely more on good old fashioned UAC for privileged auth instead of this mythical root user that can somehow always be accessed and do literally anything to a machines firmware. Maybe even lock the ROM?

[Weasel]

"sudo -s" ever heard of it? The very first command literally everyone worth any degree of engineering or security competency runs before they execute any command because Lunix permissions are a flustercuck? Would love to hear your excuse as to why root should be this special user that can modify the kernel on-demand when root is what almost all demons run under?

Lunix needs to get away from the headless-by-default scheme and rely more on good old fashioned UAC for privileged auth instead of this mythical root user that can somehow always be accessed and do literally anything to a machines firmware. Maybe even lock the ROM?

I have no idea what you're even trying to say tbh.

what part of: "sudo cp ... && sudo modprobe blah" being available without this patch you don't get?

If you have a problem with root, then that's not my problem and I wasn't arguing about it.
If you think sudo is a security issue then maybe you should use better security practices and a better password.
Otherwise I've no idea what you're even trying to say.

As long as the user that can use modprobe (root in this case) can also modify the filesystem, this patch is not a security issue. Period.

[oiaohm]

As long as the user that can use modprobe (root in this case) can also modify the filesystem, this patch is not a security issue. Period.

You are still saying this when you have not found the insmod historic cases.

what part of: "sudo cp ... && sudo modprobe blah" being available without this patch you don't get?

Because not all of them look like this.

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_basic_system_settings/managing-sudo-access_configuring-basic-system-settings#proc_configuring-sudo-privileges_managing-sudo-access

Also remember just because a user is granted sudo does not mean they are granted to run all commands. User might not be able to sudo cp because they are not granted cp as sudo.

Maybe someone should have read how sudo works before doing their post Weasel. Because why did you presume user granted right to use modprobe is also granted the right to use cp. Home installs yes enterprise business install this can be they are only granted modprobe.

Yes one of the problems is allowing modprobe to load files from where ever means a user who is only granted modprobe can now do more than what they use to be able to this include loading module of hell.

Historic examples have udev equal scripts having typo so end up loading the wrong module with insmod because some typo end up with a full path to a different kernel module than the user current running. Yes the Linux kernel feature to allow kernel modules that don't own to the current kernel to load come into play here.

In fact there is a use case why you want it to fail and add this feature to modprobe. Let say you could do modprobe "/usr/lib/modules/[kernel version]/[full path to module]
It would be useful if that function would fail when the kernel version did not match current kernel.

https://github.com/dynup/kpatch

Be very warned linux kernel modules don't just include normal drivers. They also include items like kpatch.

[Weasel]

Because not all of them look like this.

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_basic_system_settings/managing-sudo-access_configuring-basic-system-settings#proc_configuring-sudo-privileges_managing-sudo-access

Also remember just because a user is granted sudo does not mean they are granted to run all commands. User might not be able to sudo cp because they are not granted cp as sudo.

]Maybe someone should have read how sudo works before doing their post Weasel. Because why did you presume user granted right to use modprobe is also granted the right to use cp. Home installs yes enterprise business install this can be they are only granted modprobe.

In what world would you let someone use modprobe but not cp with root privileges?

modprobe can do anything since it inserts kernel module which can do absolutely everything it wants to, including expose cp functionality to any user, zero out your drive or whatever.

It's far more "dangerous" than cp.

[oiaohm]

In what world would you let someone use modprobe but not cp with root privileges?

modprobe can do anything since it inserts kernel module which can do absolutely everything it wants to, including expose cp functionality to any user, zero out your drive or whatever.

It's far more "dangerous" than cp.

Up until this change current modprobe is not that dangerous because it could only load modules that were places in the right place. Of not absolutely without risk.

There are cases where parties will be given lsmod, rmmod and modprobe with nothing else. So they can reset a driver so resetting a bit of hardware so the system comes functional again.

This use case really does mean the option to load modules anywhere on the file system need a off switch that restricts module loading to where it currently is.

Please note there are enterprise versions of sudo that log every action.

https://docs.delinea.com/online-help/server-suite/reports-events/events/server-suite/dzdo.htm

Yes like dzdo.

Just because someone is trusted to use modprobe correctly does not mean they are trust to perform cp as root.

Weasel what does need to restart driver to make a bit of hardware come functional have to do with need the cp command as root? The simple answer it does not. The common is lsmod, rmmod and modprobe handed out in combination. Not people not given insmod that can load a file from anywhere into the kernel.

This change basically without a disable switch will break existing setups.