Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

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

Summary:	TIME_ADJNTPVAL audit events not generated if there are no syscalls rules
Product:	Red Hat Enterprise Linux 8	Reporter:	Grzegorz Halat <ghalat>
Component:	kernel	Assignee:	Richard Guy Briggs <rbriggs>
kernel sub component:	Audit	QA Contact:	Dennis(Zhuoheng) Li <denli>
Status:	CLOSED CURRENTRELEASE	Docs Contact:
Severity:	low
Priority:	medium	CC:	dag, denli, georg.sauthoff, lilu, oliver, rbriggs, rik.theys, sgrubb
Version:	8.4	Keywords:	Triaged
Target Milestone:	beta	Flags:	pm-rhel: mirror+
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-10-05 18:44:46 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.