On Fr, 06.01.23 10:10, Steve Grubb (sgrubb@xxxxxxxxxx) wrote: > Hello, > > On Friday, January 6, 2023 9:33:12 AM EST Lennart Poettering wrote: > > On Do, 05.01.23 20:17, Steve Grubb (sgrubb@xxxxxxxxxx) wrote: > > > I work on RHEL security problems. I have been looking into a number of > > > exploits and I think we have a problem that has an easy fix. We are not > > > using the CONFIG_STATIC_USERMODEHELPER_PATH kernel config option. There > > > are a number of exploits that overwrite the path to modprobe and then > > > pass something weird that causes modprobe to be invoked. But instead of > > > modprobe, it's their reverse shell. > > > > umh is such a problematic interface. The processes forked off that way > > live in a weird netherworld besides the init system, in the root > > cgroup (and that even though inner cgroups in cgroupsv2 are not > > supposed to have processes in them) without any of the resource or > > security restrictions we otherwise make on all of userspace. > > One approach to solving this is to use selinux policy. selinux cannot apply resource controls, not can it arrange processes properly in the cgroup tree, nor can it apply seccomp filters, namespacing and so on. selinux can do some things, sure, but an init system is not a MAC, it does a lot more (and also a lot less). > Yeah, that's another approach that may have merit. But with the asynchronous > nature of that approach, I don't know how the kernel would know it can now > make calls into the module it needed to have loaded. Well, umh is async too in a way, kernel must wait for the userspace process to finish. There's not much of a difference to say "fork off + wait for process exit" and "send netlink message to userspace + wait for reply". Lennart -- Lennart Poettering, Berlin _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
