Closed The-Mule closed 1 year ago
Hmm, two things come to mind for debugging next steps:
audit_state
enum does not have explicit assignments so it's possible that the context->current_state
check in __audit_syscall_exit()
may not be triggering. You could try rewriting that to something like the following:
if (context->current_state != AUDIT_STATE_RECORD)
goto out;
audit_reset_context()
, making it effectively a noop. This is obviously not a fix, but it would help to potentially narrow down the root cause ... although I would try the change above first.@The-Mule do you think you could take a shot at debugging this further?
Just a hunch, but did you try exit=EACCES
instead of exit=-EACCES
?
On 2022-08-10 11:50, Ondrej Mosnáček wrote:
Just a hunch, but did you try
exit=EACCES
instead ofexit=-EACCES
?
I have tried both, but no difference.
On 2022-08-10 11:33, Paul Moore wrote:
@The-Mule do you think you could take a shot at debugging this further?
I'd already started looking at this... I'll start with your suggestions.
Great, let us know what you find out ... and please don't limit yourself to just my suggestions above :)
On 2022-08-10 12:31, Paul Moore wrote:
Great, let us know what you find out ... and please don't limit yourself to just my suggestions above :)
Ok, first suggestion is a bust. No change in behaviour.
I don't fully understand the interactions here, but this seems to help: https://gist.github.com/sergio-correia/acf68f7d0a5afe39ce42e39197d4af9d -- @rgbriggs: could please try it out and check if it makes sense?
On 2022-08-11 12:31, Sergio Correia wrote:
I don't fully understand the interactions here, but this seems to help: https://gist.github.com/sergio-correia/acf68f7d0a5afe39ce42e39197d4af9d -- @rgbriggs: could please try it out and check if it makes sense?
That doesn't change anything here. How did you come up with this?
posted v1: [PATCH ghak138] audit: move audit_return_fixup before the filters Message-Id: 7cff118972930ccb650bd62fbf0d2e8e452d729a.1661395017.git.rgb@redhat.com
posted v2 Message-Id: cover.1661449312.git.rgb@redhat.com Subject: [PATCH ghak138 v2 0/4] issues from moving beyond syscalls
upstreamed: d4fefa4801a1 (audit/stable-6.0) audit: move audit_return_fixup before the filters
I have a simple audit-testsuite test for this in my fork https://github.com/The-Mule/audit-testsuite/tree/filter-exit (it only checks exit filter for open* syscalls). Is it something we want to have in audit-testsuite?
I have a simple audit-testsuite test for this in my fork https://github.com/The-Mule/audit-testsuite/tree/filter-exit (it only checks exit filter for open* syscalls). Is it something we want to have in audit-testsuite?
I think that would be a nice addition, although I don't like the thought of the test adding and deleting users. Perhaps you could modify the test to do something that we know would always fail with a predictable error code, for example:
% echo "TESTING" > /proc/self/status
Good idea, thanks for the hint. I'll fix that and file a PR.
Great, thank you!
With the kernel fix upstream I think we can close out this issue, if anyone disagrees feel free to leave a comment in the issue and we can reopen it.
Hello folks, long time no see :).
on Fedora I am trying to catch syscalls with a specific exit value (EACCES=-13) by the following rule:
I am triggering the EACCES syscall as follows:
But there are no events generated:
What I would expect is to see something like this:
This worked until 5.15.18-100.fc34.x86_64 and stop working in 5.16.5-100.fc34.x86_64 and it is like that since then (i.e. also with 5.19.0-0.rc2.21.fc37.x86_64) It seems to be related to commit 12c5e81d3fd0a690c49dfe1c3a99bf80a24075c7 (it is also possible we are wrong here).
Is there perhaps something I am doing wrong?