Harden module auto-loading

[madaidan]

This creates a CONFIG_SECURITY_MODHARDEN option and when enabled, restricts module auto-loading to CAP_SYS_MODULE. This is based on GRKERNSEC_MODHARDEN.

[theLOICofFRANCE]

For the record, I had made a pull request of the following code:

diff --git a/kernel/kmod.c b/kernel/kmod.c
index bc6addd9152b..8bf6cee3112d 100644
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -149,6 +149,14 @@ int __request_module(bool wait, const char *fmt, ...)
 	if (ret)
 		return ret;
 
+	// equivalent to GRKERNSEC_MODHARDEN
+	if (uid_eq(current_uid(), GLOBAL_ROOT_UID)) {
+		printk(KERN_ERR
+			"warning: denied kernel module auto-load of %s\n",
+			module_name);
+		return -EPERM;
+	}
+
 	if (atomic_dec_if_positive(&kmod_concurrent_max) < 0) {
 		pr_warn_ratelimited("request_module: kmod_concurrent_max (%u) close to 0 (max_modprobes: %u), for module %s, throttling...",
 				    atomic_read(&kmod_concurrent_max),

[anthraxx]

Please perform a pull request maintenance instead by rebasing this PR and force pushing:

git checkout your-pull-request-branch
git rebase upstream/master
git push --force-with-lease origin your-pull-request-branch

[madaidan]

The rebase messed up but I fixed it with https://github.com/anthraxx/linux-hardened/pull/23/commits/a980d62664e27ee52a86163f293a92271c98654c

Would you be able to squash those other commits?

[anthraxx]

hm not really, this makes it messy to review properly and potentially apply it. Please try to fixup this pull request without creating a new one, you need to re-anchor your commits on top of this repositories current master branch. this would be a quite important exercise as rebasing against this master will be a more frequent requirement for contribution and re-creating pull requests is not good at all. looking at your tree, you may just get rid of the commits that dont belong in here, just do a git rebase --interactive HEAD~10 and do some maintenance like dropping the commits you see here that dont belong in. afterwards you can rebase against this master again to be sure you didnt discard wrong commits.

[anthraxx]

I've created a small wiki entry to help doing pull request maintenance, please take a look: https://github.com/anthraxx/linux-hardened/wiki#pull-request-maintenance

[madaidan]

I think I fixed it. Do you see anything wrong? I want to make sure I get this right before I mess up the other PRs.

[anthraxx]

looks good so far :)

[tsautereau-anssi]

There already is the kernel_module_request LSM hook, why not use that?

[madaidan]

Why create a new, more complex LSM for an if statement?

[tsautereau-anssi]

Because using LSM hooks makes code easier to maintain and much more future-proof. Sure, there might be a little more work at the beginning (although implementing a new LSM is quite quick and easy) but I think it would pay off in the long run if we're going to add multiple little hardenings of that sort. For example, it could incorporate https://github.com/anthraxx/linux-hardened/pull/41 as well.

@anthraxx Any thoughts on having a "linux-hardened LSM" to gather stuff like that?

[madaidan]

@anthraxx are you still interested in accepting these PRs?

[anthraxx]

@anthraxx are you still interested in accepting these PRs?

Yes, but the rebase has never been executed that would allow convenient review here. I pictured that you just lost interest.

The other PRs have also partially questions directed to you that you have never answered. We would appreciate a good dialogue and get things in cooperated a lot :cat:

[madaidan]

Yes, but the rebase has never been executed that would allow convenient review here.

Oh, sorry. I'll start rebasing all of them.

The other PRs have also partially questions directed to you that you have never answered.

Where exactly? I can't see any that I haven't answered.