This bug has been migrated to another issue tracking site. It has been closed here and may no longer be being monitored.

If you would like to get updates for this issue, or to participate in it, you may do so at Red Hat Issue Tracker .
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2181539 - No FANOTIFY event seen in audit log upon denial
Summary: No FANOTIFY event seen in audit log upon denial
Keywords:
Status: CLOSED MIGRATED
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: fapolicyd
Version: 8.7
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Radovan Sroka
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-03-24 13:22 UTC by Renaud Métrich
Modified: 2024-01-18 21:18 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-08-16 14:57:44 UTC
Type: Bug
Target Upstream Version:
Embargoed:
pm-rhel: mirror+

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker   RHEL-1367 0 None None None 2024-01-18 21:18:08 UTC
Red Hat Issue Tracker RHELPLAN-153025 0 None None None 2023-03-24 13:25:59 UTC
Red Hat Issue Tracker SECENGSP-5126 0 None None None 2023-03-24 13:26:09 UTC

Description Renaud Métrich 2023-03-24 13:22:24 UTC 
Description of problem:

Playing around with fapolicyd, installed on a freshly new system, with no specific post configuration performed, I noticed that denials weren't leading to FANOTIFY audit events, e.g. with `fapolicyd --debug-deny` executing:

-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
[user@vm-fapolicy8 ~]$ ./hello
-bash: ./hello: Operation not permitted

# journalctl --follow -u fapolicyd.service 
[...]
Mar 24 14:18:06 vm-fapolicy8 fapolicyd[2049]: rule=13 dec=deny_audit perm=execute auid=1000 pid=2086 exe=/usr/bin/bash : path=/home/user/hello ftype=application/x-executable trust=0

# ausearch -m FANOTIFY -ts recent
<no matches>
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Version-Release number of selected component (if applicable):

audit-3.0.7-4.el8.x86_64
fapolicyd-1.1.3-8.el8_7.1.x86_64
kernel-core-4.18.0-425.13.1.el8_7.x86_64

How reproducible:

Always

Steps to Reproduce:
1. Build a custom untrusted binary

  -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
  [user@vm-fapolicy8 ~]$ cat > hello.c << EOF
  #include <stdio.h>
  int main(int argc, char *argv[])
  {
    printf("Hello!\n");
    return 0;
  }
  EOF
  
  [user@vm-fapolicy8 ~]$ gcc -o hello hello.c
  -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

2. Try executing it

  -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
  [user@vm-fapolicy8 ~]$ ./hello
  -bash: ./hello: Operation not permitted
  -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

3. Check for audit event

  -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
  [root@vm-fapolicy8 ~]# ausearch -m FANOTIFY -ts recent
  <no matches>
  -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Actual results:

None

Expected results:

Some event
Comment 1 Radovan Sroka 2023-03-24 14:11:52 UTC 
I think that by default design nothing is sent to audit when some type of debug is there. I need to check this deeper.
Comment 2 Renaud Métrich 2023-03-24 14:15:19 UTC 
Even in non-debug nothing shows.
I tried also with booting with `audit=1` just in case.
Comment 3 Dalibor Pospíšil 2023-03-24 14:42:12 UTC 
It there at least one audit rule in place? That's the usual issue with audit messages. One needs to have at least one rules to enable logging of anything.

e.g
echo -e "-D"$'\n'"-w /etc/shadow -p w" >> /etc/audit/rules.d/audit.rules
systemctl restart auditd
Comment 4 Renaud Métrich 2023-03-24 14:48:19 UTC 
Good catch! No I don't have any.

That's clearly something to "fix" in audit daemon then, because customers may struggle (and Support) and never find anything in sosreports.

Because for AVCs, it's not the case, we get them all the time, even with no audit rule active.
Comment 5 Dalibor Pospíšil 2023-03-24 16:08:44 UTC 
Customer may not, they actually do! I'm not sure what would be the proper solution. Anyway, a BZ to at least have a discussion won't hurt.
Comment 6 Renaud Métrich 2023-03-29 09:35:08 UTC 
Filed BZ #2182660 against audit, since it's not related to FANOTIFY, it's general issue.
I lost several hours again today due to this.
Comment 7 Steve Grubb 2023-03-29 13:57:31 UTC 
This is not an audit daemon problem. The issue is that there is an inline kernel function, audit_fanotify(), called by the fanotify subsystem when an audit event is to be recorded. In it, it calls check_dummy_context(). If there are no audit rules loaded, it returns without logging the event. Because this is another security subsystem, it probably should not be subjected to the dummy context check. (SE linux is not subjected to it.) The main question would be if that check were taken away, is there/will there be enough information on hand to record something meaningful at syscall exit?

If not, then at the most fapolicyd could do a check to see if audit rules are loaded and warn if it knows decisions are to be logged to the audit system and there are no rules.
Comment 8 Renaud Métrich 2023-03-29 14:17:11 UTC 
I understand, not only fanotify is impacted but other subsystems as well (see other bz #2182660):

2246 void audit_log_path_denied(int type, const char *operation)
2247 {
2248         struct audit_buffer *ab;
2249 
2250         if (!audit_enabled || audit_dummy_context())
2251                 return;
 :
Comment 9 Steve Grubb 2023-03-29 14:23:44 UTC 
In most cases, the dummy context check is necessary due to balancing performance needs and simply being too late in the syscall to collect enough meaningful information. It would be a case by case basis to see if it can be removed.
Comment 10 Dalibor Pospíšil 2023-07-20 09:42:55 UTC 
This discussion leads me to an ultimate question: is the audit log target good default, then?
Comment 11 Steve Grubb 2023-07-20 13:05:15 UTC 
This should be re-targeted as a kernel/audit bug to get rid of the dummy_context check so that a rule is not needed.
Comment 12 Radovan Sroka 2023-08-16 14:45:03 UTC 
This bug is going to be migrated.

Contact point for migration questions or issues: rsroka
Guidance for Bugzilla users to test their Jira account or create one if needed:

https://redhat.service-now.com/help?id=kb_article_view&sysparm_article=KB0016394
https://redhat.service-now.com/help?id=kb_article_view&sysparm_article=KB0016694
https://redhat.service-now.com/help?id=kb_article_view&sysparm_article=KB0016774
Note You need to log in before you can comment on or make changes to this bug.