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. I was informed overnight that policy 38.2-1 should now enforce kernel transitions to specific helper applications. So, maybe this is solved well enough? I suppose this is easy enough to test by changing core_pattern to something else and see if we get the AVC. > It's stuff that runs in userspace but is entirely unmanaged by userspace > security and resource wise. (And it's also frickin slow) > > I wished we could get rid of umh entirely. For example, by having some > maybe netlink based protocol or so that userspace could use to > subscribe to umh events somehow and then gets the chance to fork off > the processes itself. The init system could then hook into that and > dispatch things in proper services with sandboxing, resource controls > and everything applied, in a sensible cgroup. 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. The other area that needs a good looking at the the msg_msg attack vector. -Steve _______________________________________________ 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
