[OpenRC] ALERT: BLOCK: UMH: Executing program name /lib/rc/sh/cgroup-release-agent.sh

[mrl5]

Hello,

I'm using lkrg-0.9.5 on openrc system (funtoo linux) and I'm constantly seeing this error in dmesg:

LKRG: ALERT: BLOCK: UMH: Executing program name /lib/rc/sh/cgroup-release-agent.sh

it happens always on boot and randomly later. Here are the contents of this file: https://github.com/OpenRC/openrc/blob/9b08de926b0ea2fd95d5d9f8cb3463eb3cd72d02/sh/cgroup-release-agent.sh.in -- there is also this comment in this file:

# This is run by the kernel after the last task is removed from a
# control group in the openrc hierarchy.

I don't see any side effects except this error log(s) and I see them since I started using lkrg -- I started with version 0.9.4.

Is there anything that could be done with it? I'd appreciate some guidance

[solardiz]

@mrl5 Thanks for reporting. Can you please send us a pull request adding "/lib/rc/sh/cgroup-release-agent.sh", to p_umh_global in src/modules/exploit_detection/syscalls/p_call_usermodehelper/p_call_usermodehelper.c keeping that list in alphabetical order?

[mrl5]

sure thing I can do it :) I have one question -- taking into consideration that I'm total noob in this area, but still -- could you pls confirm that this safe to add it considering:

• https://nvd.nist.gov/vuln/detail/CVE-2022-0492
• https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/
• https://blog.aquasec.com/threat-alert-container-escape
• https://0xdf.gitlab.io/2021/05/17/digging-into-cgroups.html

[Adam-pi3]

@mrl5 thanks for the PR. I can confirm it is safe to add it, more about that you can read our short write-up here: https://www.openwall.com/lists/lkrg-users/2019/07/25/1 and here: https://twitter.com/lkrg_org/status/1501586002166616069

[solardiz]

Thank you for the PR and for sharing your concern, @mrl5. Thank you for reviewing and merging this, @Adam-pi3.

My understanding is that while the most concerning attacks like the one you two referenced would involve substituting a custom program path, so would be defeated by our allow list even with this addition, there's also a subtle concern of whether any of the individual programs we allow-list could be abused in an attack. In this particular case, the script looks like it can be abused only slightly - to delete an arbitrary empty directory - although being a shell script it does also expose some attack surface. That's been our approach so far - to allow-list whatever programs systems normally invoke via UMH, and accept some imperfection in this hardening measure we have, in its default mode when the allow-list is enabled.