Open ericbrumfield opened 2 years ago
This is a good point. We will think about it.
this feature still ain't been implemented yet?
this feature still ain't been implemented yet?
Nope.
One possibility is that we add a ppid attribute which could then be matched to the kernel. We are still kicking around ideas.
Support for using ppid has been added with commit 1e1c427. Kthreads will be ppid 2. Let me know if this solves your issue.
@stevegrubb Thank you for the update! I'll try to test this as soon as I can on my end and report back. If @andrew-ma wants to beat me to testing that, then feel free to do so.
@ericbrumfield have you had a chance to check this out?
@stevegrubb I'm sorry, I haven't had time to test this yet at work. If it's available through an already packaged repo somewhere, then it might be easier and quicker for me to test by pulling an update down to a test machine sometime. I think this was released in 1.1.1? Do you know offhand if this is available upstream for RHEL to where I could snag it via dnf? If so, then I can probably test it pretty easily.
It is in Fedora 36/rawhide.
It is in Fedora 36/rawhide.
Thanks for that, I'll try to hit a copy of that this week to verify and close.
I am interested in this as well, I have RHEL machines operating fapolicyd in default deny and ran into the same problem. I needed to do the following workaround, its simpler than ericbrumfield's idea but much more open..
allow perm=open all : path=/usr/lib/systemd/systemd-cgroups-agent ftype=application/x-executable
During my testing I was able to trigger the events on rhel-8 via a service restart, however I saw also other ppids..
rule=1 dec=allow perm=execute auid=-1 pid=538593 ppid=2 exe=kworker/u6:3 : path=/usr/lib/systemd/systemd-cgroups-agent ftype=application/x-executable trust=1
rule=1 dec=allow perm=open auid=-1 pid=538593 ppid=2 exe=kworker/u6:3 : path=/usr/lib/systemd/systemd-cgroups-agent ftype=application/x-executable trust=1
rule=1 dec=allow perm=execute auid=-1 pid=538593 ppid=2 exe=kworker/u6:3 : path=/usr/lib64/ld-2.28.so ftype=application/x-sharedlib trust=1
rule=1 dec=allow perm=open auid=-1 pid=538593 ppid=2 exe=kworker/u6:3 : path=/usr/lib64/ld-2.28.so ftype=application/x-sharedlib trust=1
rule=10 dec=allow perm=execute auid=-1 pid=538619 ppid=528128 exe=kworker/u6:3 : path=/usr/bin/kmod ftype=application/x-executable trust=1
rule=15 dec=allow perm=open auid=-1 pid=538619 ppid=528128 exe=kworker/u6:3 : path=/usr/bin/kmod ftype=application/x-executable trust=1
rule=10 dec=allow perm=execute auid=-1 pid=538619 ppid=528128 exe=kworker/u6:3 : path=/usr/lib64/ld-2.28.so ftype=application/x-sharedlib trust=1
rule=8 dec=allow perm=open auid=-1 pid=538619 ppid=528128 exe=kworker/u6:3 : path=/usr/lib64/ld-2.28.so ftype=application/x-sharedlib trust=1
rule=10 dec=allow perm=execute auid=-1 pid=538623 ppid=528128 exe=kworker/u6:3 : path=/usr/bin/kmod ftype=application/x-executable trust=1
rule=15 dec=allow perm=open auid=-1 pid=538623 ppid=528128 exe=kworker/u6:3 : path=/usr/bin/kmod ftype=application/x-executable trust=1
rule=10 dec=allow perm=execute auid=-1 pid=538623 ppid=528128 exe=kworker/u6:3 : path=/usr/lib64/ld-2.28.so ftype=application/x-sharedlib trust=1
rule=8 dec=allow perm=open auid=-1 pid=538623 ppid=528128 exe=kworker/u6:3 : path=/usr/lib64/ld-2.28.so ftype=application/x-sharedlib trust=1
rule=10 dec=allow perm=execute auid=-1 pid=538640 ppid=528128 exe=kworker/u6:3 : path=/usr/bin/kmod ftype=application/x-executable trust=1
rule=15 dec=allow perm=open auid=-1 pid=538640 ppid=528128 exe=kworker/u6:3 : path=/usr/bin/kmod ftype=application/x-executable trust=1
rule=10 dec=allow perm=execute auid=-1 pid=538640 ppid=528128 exe=kworker/u6:3 : path=/usr/lib64/ld-2.28.so ftype=application/x-sharedlib trust=1
rule=8 dec=allow perm=open auid=-1 pid=538640 ppid=528128 exe=kworker/u6:3 : path=/usr/lib64/ld-2.28.so ftype=application/x-sharedlib trust=1
rule=10 dec=allow perm=execute auid=-1 pid=538642 ppid=528128 exe=kworker/u6:3 : path=/usr/bin/kmod ftype=application/x-executable trust=1
rule=15 dec=allow perm=open auid=-1 pid=538642 ppid=528128 exe=kworker/u6:3 : path=/usr/bin/kmod ftype=application/x-executable trust=1
rule=10 dec=allow perm=execute auid=-1 pid=538642 ppid=528128 exe=kworker/u6:3 : path=/usr/lib64/ld-2.28.so ftype=application/x-sharedlib trust=1
rule=8 dec=allow perm=open auid=-1 pid=538642 ppid=528128 exe=kworker/u6:3 : path=/usr/lib64/ld-2.28.so ftype=application/x-sharedlib trust=1
rule=1 dec=allow perm=execute auid=-1 pid=538677 ppid=2 exe=kworker/u6:3 : path=/usr/lib/systemd/systemd-cgroups-agent ftype=application/x-executable trust=1
rule=1 dec=allow perm=open auid=-1 pid=538677 ppid=2 exe=kworker/u6:3 : path=/usr/lib/systemd/systemd-cgroups-agent ftype=application/x-executable trust=1
rule=1 dec=allow perm=execute auid=-1 pid=538677 ppid=2 exe=kworker/u6:3 : path=/usr/lib64/ld-2.28.so ftype=application/x-sharedlib trust=1
rule=1 dec=allow perm=open auid=-1 pid=538677 ppid=2 exe=kworker/u6:3 : path=/usr/lib64/ld-2.28.so ftype=application/x-sharedlib trust=1
Note I added rule 1 allow perm=any ppid=2 : all
Recently in using fapolicyd we've started intermittently seeing denials come up like the following around kworker. Our setup requires us to deny anything not whitelisted at the end per a STIG:
The kworker/uT:J can be allowed if I build up a large set of the combination of values, say of T and J where each goes from 0 to 64 in value, creating a large csv string and configuring it into a set like:
and then use that in a rule like:
I'm not sure if what we're doing may be a weird setup where these kworker invocations get intermittently blocked by fapolicyd and denied. Allowing it via a set we generate and allow it to execute in our rule above though works well, it's just the range of the values is unknown and can be different on different virtualized machines we're running. The above with a set is the best way I know to handle this, but wanted to create an issue to ask this question and maybe pose a feature request for the ability to either have a way to reduce the rule size by either having fapolicyd generate a range in its rule evaluation or maybe use a regular expression in order to reduce the length of our rules?
If there is a concept of an int range to use, or even a regex here in a rule it'd reduce the size of our rule quite a bit. Something like this below concept:
Even a \d+ could work there and cover everything with a regex concept.