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

[panikal]

you could always use insmod to load a module from anywhere you want.
now modprobe can do that too. this changes nothing about security

Yeah this is like apt-get or yum/dnf vs rpm or deb. insmod requires you to load all dependencies manually. modprobe loads them for you if possible. Now modprobe can do what insmod does and also autoload dependencies, when possible. Just saves time, doesn't change behavior really...

[stormcrow]

Not a security issue.

1. insmod already has this feature
2. modprobe & insmod require elevated privileges to do more than list modules already inserted
3. given (2), if someone already has managed elevated privileges, then restricting file reads to areas only root generally has write permissions will not save you
4. if someone has executed a privilege escalation attack there's very little to prevent said someone from altering SELinux or AppArmor profiles en mass nor from dropping their compromised modules into the traditional directories for modules.
5. Properly executed boot, module/driver signing, and execution chains of trust is what help prevent 2, 3, & 4 from occurring in the first place.

Linux security takes work. No Linux distro is "secure" out of the box. You have to work to make it (more) so, just like you have to work to make Windows (more) secure - and you start with the same tools and concepts for both with only the details differing.

[qlum]

Not a security expert by any means but turning it around does seem like it makes it a little easier to create security mistakes. If you somehow placed a kernel module somewhere a unprivilaged user could override it somehow. It could be a problem when the module gets loaded. Granted probably a stupid oversight but Enforcing a location keeps things a bit more contained.

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

[gavron]

Loading kernel modules requires elevated privileges anyway, but... making it easier to load kernel modules from non-system directories, and therefore having to weaken security policies which enforce the former defaults, does not strike me as a security improvement.
It's typically the kind of things that I feel spender would lambast. Not that I can easily check for that on his Twitter feed, though, with this new brain-dead, worse than useless behaviour of Twitter displaying tweets in random order instead of chronological order...

I wholeheartedly agree with the first part. I'd hope that the very least some sanity checks are added to ensure
1. All modules loaded from outside the modules directory will generate a kprintf (dmesg log) that shows module name, file location, and possibly a checksum
2. A module named the same as an existing one can't be loaded from outside the modules directory (i.e. no counterfeiting, to use a poker hand term)
3. If unsigned or if the signature doesn't match the kernel's source signature a 'taints kern' message is logged

As to the twitter thing, that's the fault of people everywhere who use twitter as a Changelog, a calendar, a news feed, a fanboi page, or an advertisement display location. While it can do those things, it doesn't do them well, and now does so much worse. Rather than expressing disappointment that twitter doesn't live up to anyone's expectations anymore (if ever) probably it would be more prudent to use more reliable trustworthy tools or sources.

I really like my Leatherman Wave. It's pretty good at lots of things. However, it is not great at any of them. That's like Twitter.

E

[kylew77]

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.

[jacob]

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.

Removing kernel module loading would be a nonstarter for Linux. The proper solution lies around secure boot and signature validation.

[AlanTuring69]

As an IT security professional working at a company of > 200 people, this change is completely insane, barbaric, and shortsighted. Now anyone can load their modprobes from anywhere?? Surely someone, somewhere, realized that there is security in requiring modules to exist in a tightly controlled directory with group structure and SELinux permissions.

I'm moving to MINIX. Linus will never win the unix wars.

[onlyLinuxLuvUBack]

As an IT security professional working at a company of > 200 people, this change is completely insane, barbaric, and shortsighted. Now anyone can load their modprobes from anywhere?? Surely someone, somewhere, realized that there is security in requiring modules to exist in a tightly controlled directory with group structure and SELinux permissions.

I'm moving to MINIX. Linus will never win the unix wars.

I think templeOS has the droids you are looking for without evil networks.

[jacob]

Not a security expert by any means but turning it around does seem like it makes it a little easier to create security mistakes. If you somehow placed a kernel module somewhere a unprivilaged user could override it somehow. It could be a problem when the module gets loaded. Granted probably a stupid oversight but Enforcing a location keeps things a bit more contained.

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

You realise that this is only a change in one command line tool that doesn't affect the security of the kernel in any way? Anyone could and can a write their own "modprobe" to load kernel modules from wherever. The entire security of the mechanism relies entirely on the init_module() system call. No changes to user space tools make any difference to that, just like file access control doesn't depend on the "cat" utility.

[andresdju]

I'm not saying that I disagree with this change, but:

Not a security issue.

If something related with capabilities change, it's difficult to be sure if it has security implications.

insmod already has this feature

A buggy script that runs modprobe with module names from a parsed file could be tricked to load modules from ~/Downloads. Before this change, modprobe would fail, now it could load a malicious module from somewhere else. Making a bug in parsing a file execute arbitrary code or running another command (insmod) could be more difficult. Also, as an administrator, it's usual to load modules from the standard directories with modprobe, not easy, but not crazy that someone could run modprobe ./module_name by mistake.

[*]Properly executed boot...

We should reduce the risks even with not correctly written programs or not properly executed boot, signing etc. Again, not saying that this will be a problem, but sometimes it took a lot of years before someone found security implications of something it looked right.

I kind of remember that someone argued that Linux allowing execve() a program when argc is 0 was a potential security risk, other thought that it was not a security issue. Years later a bug in PolicyKit's pkexec affected Linux but not OpenBSD (because its kernel refuses to execve() a program if argc is 0). So yes, a properly written pkexec would have solved the problem in the first place, but not enough of a comfort when it is not.