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 1991919 - TIME_ADJNTPVAL audit events not generated if there are no syscalls rules
Summary: TIME_ADJNTPVAL audit events not generated if there are no syscalls rules
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: kernel
Version: 8.4
Hardware: All
OS: Linux
medium
low
Target Milestone: beta
: ---
Assignee: Richard Guy Briggs
QA Contact: Dennis(Zhuoheng) Li
URL:
Whiteboard:
: 2095735 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-08-10 11:59 UTC by Grzegorz Halat
Modified: 2022-10-05 18:44 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-10-05 18:44:46 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-93012 0 None None None 2021-08-10 12:02:38 UTC

Description Grzegorz Halat 2021-08-10 11:59:17 UTC 
Description of problem:
TIME_ADJNTPVAL events are not generated in case of no syscalls rules.

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

How reproducible:
Always

Steps to Reproduce:

Test 1:
1. Clear all auditd rules
   # auditctl -D
2. Clear auditd logs
   # echo  >/var/log/audit/audit.log
3. Trigger time change:
systemctl stop chronyd.service ; timedatectl set-time 03:27 ; systemctl start chronyd.service

Test 2:
1. Clear all auditd rules
   # auditctl -D
2. Clear auditd logs
   # echo  >/var/log/audit/audit.log
3. Add random syscall rule unrelated to time keeping, for example 
   #auditctl -a always,exit -F arch=b64 -S execve,execveat -F auid!=-1 -F key=EXECVE
4. Trigger time change:
systemctl stop chronyd.service ; timedatectl set-time 03:27 ; systemctl start chronyd.service


Actual results:
Test 1 - TIME_ADJNTPVAL event was not logged by the kernel
Test 2 - TIME_ADJNTPVAL event was logged

Expected results:
I think that expected behaviour is TIME_ADJNTPVAL should always be logged, even when there are no syscall rules. 
The current behaviour is a bit confusing.After adding a rule unrelated to time keeping a new, unexpected TIME_ADJNTPVAL event is being logged.

Additional info:
TIME_ADJNTPVAL was introduced in:
https://bugzilla.redhat.com/show_bug.cgi?id=1680034
Comment 4 Steve Grubb 2021-11-03 14:22:10 UTC 
This event is not supposed to be hardwired - meaning automatic. People will be very unhappy if that were the case. Because you don't get just 1 event, get get several each time there is a sync. And you get a sync pretty often. Meaning, that if this were on by default, it could potentially make a lot of events.  It should not be triggered by the presence of just any old syscall rule. Rather you should need to place syscall rules on the time setting syscalls to trigger this.
Comment 5 Richard Guy Briggs 2021-11-10 16:59:57 UTC 
2021-11-04: RFC patch v1 posted upstream https://listman.redhat.com/archives/linux-audit/2021-November/msg00024.html
Comment 9 Richard Guy Briggs 2022-01-24 19:00:32 UTC 
2022-01-21: posted v2 upstream https://lore.kernel.org/all/9bd09a6b4433094803195a037ff59301a24eafc9.1642774100.git.rgb@redhat.com/
Comment 10 Richard Guy Briggs 2022-01-26 12:23:17 UTC 
2022-01-25: post v3 upstream https://lore.kernel.org/r/120b8aa605c9ee07fb300d433e136e261b27d6b2.1643167327.git.rgb@redhat.com
Comment 11 Richard Guy Briggs 2022-02-16 20:37:27 UTC 
2022-02-14 post v4 https://lore.kernel.org/r/8581d6f4b9e732d11c258fe850666f1eefab828f.1644621720.git.rgb@redhat.com
2022-02-16 post v5 https://lore.kernel.org/r/d97744aaeee1cce34f793dabf9ce035354d73250.1645043410.git.rgb@redhat.com
Comment 12 Richard Guy Briggs 2022-02-22 19:34:17 UTC 
2022-02-22 post v6 https://lore.kernel.org/r/37bcf09f68a9d711ed350d85169d4aa1abcb7775.1645140903.git.rgb@redhat.com

upstreamed: 272ceeaea355 audit: log AUDIT_TIME_* records only from rules
Comment 15 Richard Guy Briggs 2022-06-11 02:09:07 UTC 
*** Bug 2095735 has been marked as a duplicate of this bug. ***
Comment 16 Georg Sauthoff 2022-09-29 16:55:35 UTC 
(In reply to Steve Grubb from comment #4)
> This event is not supposed to be hardwired - meaning automatic. People will
> be very unhappy if that were the case. Because you don't get just 1 event,
> get get several each time there is a sync. And you get a sync pretty often.
> Meaning, that if this were on by default, it could potentially make a lot of
> events.  It should not be triggered by the presence of just any old syscall
> rule. Rather you should need to place syscall rules on the time setting
> syscalls to trigger this.

I couldn't agree more. But since this bug is still open, is the originally proposed change going forward into RHEL8, or not?

However, on a RHEL8 server with 4.18.0-372.26.1.el8_6.x86_64 kernel (and just a few filesystem object audit rules and 2 unrelated syscall audit rules), I already get massively spammed by type=TIME_ADJNTPVAL and syscall=305 audit messages after starting a PTP daemon (sfptpd).

Since the PTP daemon is calling clock_adjtime at a rate of 36 (!) per second, the audit log spam is quite excessive.

Ok, I'm observing this when other audit syscall rules are active (i.e. just on sethostname,setdomainname) and this issue is about a situation where no syscall rules are active, at all.
But this seems to be a weird default for that situation, also, right?

Or would that be considered 'works as designed'?

FWIW, my workaround is to disable this current default (?) via:

auditctl -a never,exclude -F msgtype=TIME_ADJNTPVAL

(`auditctl -D` is also a good work-around)
Comment 17 Richard Guy Briggs 2022-10-05 18:44:46 UTC 
(In reply to Georg Sauthoff from comment #16)
> I couldn't agree more. But since this bug is still open, is the originally
> proposed change going forward into RHEL8, or not?

It is in RHEL8.7 kernel-4.18.0-399.el8.
Note You need to log in before you can comment on or make changes to this bug.