BUG: rules with 'exit' filter do not generate any audit events

[The-Mule]

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:

# auditctl -a always,exit -S all -F exit=-13 -F key=eacces
# auditctl -l
-a always,exit -S all -F exit=-EACCES -F key=eacces

I am triggering the EACCES syscall as follows:

# useradd testuser
# su - testuser
$ whoami
$ date
10:01:34
$ cat /etc/shadow
cat: /etc/shadow: Permission denied
$ strace -f cat /etc/shadow 2>strace.log
$ grep -e shadow  strace.log | grep EACCES
openat(AT_FDCWD, "/etc/shadow", O_RDONLY) = -1 EACCES (Permission denied)
$ logout

But there are no events generated:

# ausearch -ts 10:01:34 -k eacces
<no matches>
# ausearch -ts 10:01:34 
----
time->Wed Aug 10 10:01:34 2022
type=SERVICE_STOP msg=audit(1660140094.799:510): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
----
time->Wed Aug 10 10:01:44 2022
type=USER_END msg=audit(1660140104.987:511): pid=1229 uid=0 auid=0 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_close grantors=pam_keyinit,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_umask,pam_xauth acct="testuser" exe="/usr/bin/su" hostname=? addr=? terminal=/dev/pts/0 res=success'
----
time->Wed Aug 10 10:01:44 2022
type=CRED_DISP msg=audit(1660140104.987:512): pid=1229 uid=0 auid=0 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_rootok acct="testuser" exe="/usr/bin/su" hostname=? addr=? terminal=/dev/pts/0 res=success'
----
time->Wed Aug 10 10:01:54 2022
type=SERVICE_STOP msg=audit(1660140114.793:513): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
----
time->Wed Aug 10 10:01:54 2022
type=BPF msg=audit(1660140114.798:514): prog-id=0 op=UNLOAD
----
time->Wed Aug 10 10:01:54 2022
type=BPF msg=audit(1660140114.798:515): prog-id=0 op=UNLOAD

What I would expect is to see something like this:

type=PROCTITLE msg=audit(...) : proctitle=bash -c cat /etc/shadow 
type=PATH msg=audit(...) ...
type=CWD msg=audit(...) : ...
type=SYSCALL msg=audit(...) : arch=x86_64 syscall=openat success=no exit=EACCES(Permission denied) ... uid=testuser gid=testuser euid=testuser suid=testuser fsuid=testuser egid=testuser sgid=testuser fsgid=testuser tty=(none) ses=4 comm=cat exe=/usr/bin/cat ... key=eacces

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?

[pcmoore]

Hmm, two things come to mind for debugging next steps:

• The 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;

• While I don't think this is an issue, you could try immediately returning in 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?

[WOnder93]

Just a hunch, but did you try exit=EACCES instead of exit=-EACCES?

[rgbriggs]

On 2022-08-10 11:50, Ondrej Mosnáček wrote:

Just a hunch, but did you try exit=EACCES instead of exit=-EACCES?

I have tried both, but no difference.

[rgbriggs]

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.

[pcmoore]

Great, let us know what you find out ... and please don't limit yourself to just my suggestions above :)

[rgbriggs]

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.

[sergio-correia]

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?

[rgbriggs]

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?

[rgbriggs]

posted v1: [PATCH ghak138] audit: move audit_return_fixup before the filters Message-Id: 7cff118972930ccb650bd62fbf0d2e8e452d729a.1661395017.git.rgb@redhat.com

[rgbriggs]

posted v2 Message-Id: [email protected] Subject: [PATCH ghak138 v2 0/4] issues from moving beyond syscalls

[rgbriggs]

upstreamed: d4fefa4801a1 (audit/stable-6.0) audit: move audit_return_fixup before the filters

[The-Mule]

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?

[pcmoore]

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

[The-Mule]

Good idea, thanks for the hint. I'll fix that and file a PR.

[pcmoore]

Great, thank you!

[pcmoore]

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.