fapolicyd blocks in permissive mode #216
Comments
|
Hello, Are there any AVC?
Not really. But I would say it does not matter in this case. |
|
I have yet to see any denies from SELinux when this error occurs, but am more than happy to double check when the I can get the issue to occur again. |
|
All kernel checks that return EPERM in the fanotify code require CAP_SYS_ADMIN...which we leave on. This is strange because poll has just told us there is something to read and then we go through 4 if statements and read. Read is not normally the enforcement point of policy, opening the descriptor is where that is done. I can't see how that errno is returned. If you change to an 8.6 or 8.5 kernel, does it also lockup? And you are saying that has been see on multiple machines? |
|
The servers I am mainly having issues with are all running Axway SecureTransport, but the policy listed below is currently in development, and is on around 30 servers. I have not been able to clone the VM to downgrade kernels yet; I can try that soon. I'm not 100% sure what is causing the issue to trigger, since this same policy is on two other servers running SecureTransport. If I do swap kernels and can't replicate the issue, I will be unsure whether or not it is because I am doing something incorrectly to reproduce, or if that actually solves the problem. I cannot remember for certain whether or not this issue has occurred on other hosts, but I don't believe it has. I will check with my coworkers tomorrow. Server info (latest kernel is the one running)Below is an example trigger from Ansible, since it's easily reproducable:Here is what that failure looks like on the client with issuesCurrent fapolicyd configurationCurrent policyAn additional fapolicyd output in debug mode:Searching for any AVC messages |
|
Does Axway SecureTransport have any kernel modules? This problem is originating in the kernel. It won't matter what policy or configuration fapolicyd has. The read syscall is failing with EPERM. If there are 3rd party kernel modules being loaded, I'd suggest unloading them and then trying fapolicyd again. |
|
Also, there is no way to tell the kernel to allow access because the read that is failing has the metadata that we need to use to grant access. |
|
Hello, I don't think Axway ST has any of its own kernel modules, but it does have a few additional that I've noticed so far over our baseline. These servers are serving and working with files (mainly .txts) on a mounted NFS share, if that helps: There is a 3rd Axway ST server that is not using NFS shares. So far, we have not experienced the issue on that server. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Under certain circumstances, I am getting an fapolicyd error where fapolicyd is seemingly ignoring all rules in rules.d/ and blocking. When this occurs, any time that a rule should be hit to permit, the error "
Error receiving fanotify_event (Permission denied)"I am currently unsure what is causing the issue; a reboot has fixed it on one machine, but I ended up reimaging another rather than taking the time to figure it out. Troubleshooting so far has not been successful. Red Hat has a snippet
In rare cases, removing the fapolicyd pipe file can solve a lockup, but doesn't mention what those rare cases look like. Running the mentioned command does not seem to fix the issue.It seems that the relevant code for the error seems to be on line 374 of notify.c: https://github.com/linux-application-whitelisting/fapolicyd/blob/main/src/daemon/notify.c#L374.
I am more than happy to produce any troubleshooting data or rules files when this issue pops up again. Currently these systems are running RHEL 8.7 and fully STIGed, minus fapolicyd in permissive mode and SELinux user contexts.
At the least, when this error is hit, is it possible to recognize that fapolicyd is in permissive mode and fail open?
The text was updated successfully, but these errors were encountered: