Question regarding ntpd

Question regarding ntpd

[Sullivan, Daniel [CRI]]

Hi,

I have what I hope to be a quick question regarding auditing ntpd.  I am looking at my auditd log file and I see this same entry being repeated every second:

type=SYSCALL msg=audit(1475012493.972:5325): arch=c000003e syscall=159 success=yes exit=0 a0=7ffd7498eb00 a1=861 a2=0 a3=1 items=0 ppid=1 pid=5357 auid=4294967295 uid=38 gid=38 euid=38 suid=38 fsuid=38 egid=38 sgid=38 fsgid=38 tty=(none) ses=4294967295 comm="ntpd" exe="/usr/sbin/ntpd" key="time-change"
type=SYSCALL msg=audit(1475012494.971:5326): arch=c000003e syscall=159 success=yes exit=0 a0=7ffd7498eb00 a1=861 a2=0 a3=1 items=0 ppid=1 pid=5357 auid=4294967295 uid=38 gid=38 euid=38 suid=38 fsuid=38 egid=38 sgid=38 fsgid=38 tty=(none) ses=4294967295 comm="ntpd" exe="/usr/sbin/ntpd" key="time-change"
type=SYSCALL msg=audit(1475012495.972:5327): arch=c000003e syscall=159 success=yes exit=0 a0=7ffd7498eb00 a1=861 a2=0 a3=1 items=0 ppid=1 pid=5357 auid=4294967295 uid=38 gid=38 euid=38 suid=38 fsuid=38 egid=38 sgid=38 fsgid=38 tty=(none) ses=4294967295 comm="ntpd" exe="/usr/sbin/ntpd" key="time-change”

This is generating large amounts of log data.  I am not an expert in auditd log analysis.  Is this expected behavior?  I am unsure of what the key time-change value of this log data is, and am wondering if this indicates some sort of misconfiguration or problem with ntpd.  From looking at the output of tcpdump it does not look like I am polling every second, so I am wondering why this activity is occurring.   If anybody could advise on how to decipher these log entries I would appreciate it.  Thank you for your help and advisement.

Best,

Dan Sullivan




********************************************************************************
This e-mail is intended only for the use of the individual or entity to which
it is addressed and may contain information that is privileged and confidential.
If the reader of this e-mail message is not the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this
communication is prohibited. If you have received this e-mail in error, please 
notify the sender and destroy all copies of the transmittal. 

Thank you
University of Chicago Medicine and Biological Sciences 
********************************************************************************

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: Question regarding ntpd

[Steve Grubb]

On Tuesday, September 27, 2016 10:05:31 PM EDT Sullivan, Daniel [CRI] wrote:
> type=SYSCALL msg=audit(1475012495.972:5327): arch=c000003e syscall=159
> success=yes exit=0 a0=7ffd7498eb00 a1=861 a2=0 a3=1 items=0 ppid=1 pid=5357
> auid=4294967295 uid=38 gid=38 euid=38 suid=38 fsuid=38 egid=38 sgid=38
> fsgid=38 tty=(none) ses=4294967295 comm="ntpd" exe="/usr/sbin/ntpd"
> key="time-change”
> 
> This is generating large amounts of log data.

Yep.

> I am not an expert in auditd log analysis.  Is this expected behavior? 

Unfortunately for that syscall yes. Your best option is to not audit that 
syscall.


> I am unsure of what the key time-change value of this log data is, and am
> wondering if this indicates some sort of misconfiguration or problem with
> ntpd.

Keys are used for reporting. You can run 
aureport --start today --key --summary
to get an idea of what kinds of events you are getting. You can also use keys 
with ausearch to extract events that trigger on a specific rule and then feed 
that to aureport.


> From looking at the output of tcpdump it does not look like I am polling
> every second, so I am wondering why this activity is occurring.   If anybody
> could advise on how to decipher these log entries I would appreciate it. 
> Thank you for your help and advisement.

Well, using the -i option to ausearch gives more meaning:

type=SYSCALL msg=audit(09/27/2016 17:41:35.972:5327) : arch=x86_64 
syscall=adjtimex success=yes exit=0 a0=0x7ffd7498eb00 a1=0x861 a2=0x0 a3=0x1 
items=0 ppid=1 pid=5357 auid=unset uid=ntp gid=ntp euid=ntp suid=ntp fsuid=ntp 
egid=ntp sgid=ntp fsgid=ntp tty=(none) ses=unset comm=ntpd exe=/usr/sbin/ntpd 
key=time-change

But the syscall uses a single data struct and we have no visibility into that 
so we cannot tell any more what its doing.

The whole point of monitoring the time settings is that someone could tamper 
with logs or cause something to appear like it occurred at a different time 
than it really did. So, the idea is to collect this info "in case". But ntpd 
overwhelms logs but chronyd might be marginally better. See bz

https://bugzilla.redhat.com/show_bug.cgi?id=918127

for some discussion.

-Steve

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: Question regarding ntpd

[John Jasen]

Reading this, my first thought was ntpd trying to adjust time drift on
the client.


On 09/27/2016 07:16 PM, Steve Grubb wrote:
> On Tuesday, September 27, 2016 10:05:31 PM EDT Sullivan, Daniel [CRI] wrote:
>> type=SYSCALL msg=audit(1475012495.972:5327): arch=c000003e syscall=159
>> success=yes exit=0 a0=7ffd7498eb00 a1=861 a2=0 a3=1 items=0 ppid=1 pid=5357
>> auid=4294967295 uid=38 gid=38 euid=38 suid=38 fsuid=38 egid=38 sgid=38
>> fsgid=38 tty=(none) ses=4294967295 comm="ntpd" exe="/usr/sbin/ntpd"
>> key="time-change”
>>
>> This is generating large amounts of log data.
> Yep.
>
>> I am not an expert in auditd log analysis.  Is this expected behavior? 
> Unfortunately for that syscall yes. Your best option is to not audit that 
> syscall.
>
>
>> I am unsure of what the key time-change value of this log data is, and am
>> wondering if this indicates some sort of misconfiguration or problem with
>> ntpd.
> Keys are used for reporting. You can run 
> aureport --start today --key --summary
> to get an idea of what kinds of events you are getting. You can also use keys 
> with ausearch to extract events that trigger on a specific rule and then feed 
> that to aureport.
>
>
>> From looking at the output of tcpdump it does not look like I am polling
>> every second, so I am wondering why this activity is occurring.   If anybody
>> could advise on how to decipher these log entries I would appreciate it. 
>> Thank you for your help and advisement.
> Well, using the -i option to ausearch gives more meaning:
>
> type=SYSCALL msg=audit(09/27/2016 17:41:35.972:5327) : arch=x86_64 
> syscall=adjtimex success=yes exit=0 a0=0x7ffd7498eb00 a1=0x861 a2=0x0 a3=0x1 
> items=0 ppid=1 pid=5357 auid=unset uid=ntp gid=ntp euid=ntp suid=ntp fsuid=ntp 
> egid=ntp sgid=ntp fsgid=ntp tty=(none) ses=unset comm=ntpd exe=/usr/sbin/ntpd 
> key=time-change
>
> But the syscall uses a single data struct and we have no visibility into that 
> so we cannot tell any more what its doing.
>
> The whole point of monitoring the time settings is that someone could tamper 
> with logs or cause something to appear like it occurred at a different time 
> than it really did. So, the idea is to collect this info "in case". But ntpd 
> overwhelms logs but chronyd might be marginally better. See bz
>
> https://bugzilla.redhat.com/show_bug.cgi?id=918127
>
> for some discussion.
>
> -Steve
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: Question regarding ntpd

[Sullivan, Daniel [CRI]]

Actually this is kind of where my head was at too.  It just didn’t look like there was any meaningful data in the audit entry (i.e. actual time values).  I appreciate you taking the time to get back to me.

Also, FWIW I am completely new to auditd.

Dan

> On Sep 27, 2016, at 7:06 PM, John Jasen <jjasen@gmail.com> wrote:
> 
> Reading this, my first thought was ntpd trying to adjust time drift on
> the client.
> 
> 
> On 09/27/2016 07:16 PM, Steve Grubb wrote:
>> On Tuesday, September 27, 2016 10:05:31 PM EDT Sullivan, Daniel [CRI] wrote:
>>> type=SYSCALL msg=audit(1475012495.972:5327): arch=c000003e syscall=159
>>> success=yes exit=0 a0=7ffd7498eb00 a1=861 a2=0 a3=1 items=0 ppid=1 pid=5357
>>> auid=4294967295 uid=38 gid=38 euid=38 suid=38 fsuid=38 egid=38 sgid=38
>>> fsgid=38 tty=(none) ses=4294967295 comm="ntpd" exe="/usr/sbin/ntpd"
>>> key="time-change”
>>> 
>>> This is generating large amounts of log data.
>> Yep.
>> 
>>> I am not an expert in auditd log analysis.  Is this expected behavior? 
>> Unfortunately for that syscall yes. Your best option is to not audit that 
>> syscall.
>> 
>> 
>>> I am unsure of what the key time-change value of this log data is, and am
>>> wondering if this indicates some sort of misconfiguration or problem with
>>> ntpd.
>> Keys are used for reporting. You can run 
>> aureport --start today --key --summary
>> to get an idea of what kinds of events you are getting. You can also use keys 
>> with ausearch to extract events that trigger on a specific rule and then feed 
>> that to aureport.
>> 
>> 
>>> From looking at the output of tcpdump it does not look like I am polling
>>> every second, so I am wondering why this activity is occurring.   If anybody
>>> could advise on how to decipher these log entries I would appreciate it. 
>>> Thank you for your help and advisement.
>> Well, using the -i option to ausearch gives more meaning:
>> 
>> type=SYSCALL msg=audit(09/27/2016 17:41:35.972:5327) : arch=x86_64 
>> syscall=adjtimex success=yes exit=0 a0=0x7ffd7498eb00 a1=0x861 a2=0x0 a3=0x1 
>> items=0 ppid=1 pid=5357 auid=unset uid=ntp gid=ntp euid=ntp suid=ntp fsuid=ntp 
>> egid=ntp sgid=ntp fsgid=ntp tty=(none) ses=unset comm=ntpd exe=/usr/sbin/ntpd 
>> key=time-change
>> 
>> But the syscall uses a single data struct and we have no visibility into that 
>> so we cannot tell any more what its doing.
>> 
>> The whole point of monitoring the time settings is that someone could tamper 
>> with logs or cause something to appear like it occurred at a different time 
>> than it really did. So, the idea is to collect this info "in case". But ntpd 
>> overwhelms logs but chronyd might be marginally better. See bz
>> 
>> https://bugzilla.redhat.com/show_bug.cgi?id=918127
>> 
>> for some discussion.
>> 
>> -Steve
>> 
>> --
>> Linux-audit mailing list
>> Linux-audit@redhat.com
>> https://www.redhat.com/mailman/listinfo/linux-audit
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit


********************************************************************************
This e-mail is intended only for the use of the individual or entity to which
it is addressed and may contain information that is privileged and confidential.
If the reader of this e-mail message is not the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this
communication is prohibited. If you have received this e-mail in error, please 
notify the sender and destroy all copies of the transmittal. 

Thank you
University of Chicago Medicine and Biological Sciences 
********************************************************************************

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: Question regarding ntpd

[Ryan Sawhill]

[-- Attachment #1.1: Type: text/plain, Size: 546 bytes --]

To say the thing that Steve knows but didn't explicitly point out:

The "time-change" key is used in the standard STIG rules. If you can get
the clearance from the powers-that-be in your org, note that the auditctl
rule format allows you to exclude time-change events generated by something
that you want to trust, e.g., ntpd. I wrote an article for this exact issue
recently on the Red Hat Customer Portal. See: How to exclude specific
users, groups, or services when using auditd to audit syscalls
<https://access.redhat.com/solutions/2477471>

[-- Attachment #1.2: Type: text/html, Size: 615 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Question regarding ntpd

[Sullivan, Daniel [CRI]]

Thank you for chiming in, Ryan.  I saw a thread describing a similar strategy out there, what was confusing me was really two fold;

1) the entries being generated every second (i.e. outside of whatever perceived polling interval was configured).
2) the entries apparently not having any meaningful information (if presumably some sort of adjustment was being made); perhaps the -i switch Steve provided will account for this.

I think the responses provided are enough to point me in the right direction.  Thank you for your help.

Dan


On Sep 27, 2016, at 7:21 PM, Ryan Sawhill <rsawhill@redhat.com<mailto:rsawhill@redhat.com>> wrote:

To say the thing that Steve knows but didn't explicitly point out:

The "time-change" key is used in the standard STIG rules. If you can get the clearance from the powers-that-be in your org, note that the auditctl rule format allows you to exclude time-change events generated by something that you want to trust, e.g., ntpd. I wrote an article for this exact issue recently on the Red Hat Customer Portal. See: How to exclude specific users, groups, or services when using auditd to audit syscalls<https://access.redhat.com/solutions/2477471>
--
Linux-audit mailing list
Linux-audit@redhat.com<mailto:Linux-audit@redhat.com>
https://www.redhat.com/mailman/listinfo/linux-audit

********************************************************************************
This e-mail is intended only for the use of the individual or entity to which
it is addressed and may contain information that is privileged and confidential.
If the reader of this e-mail message is not the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this
communication is prohibited. If you have received this e-mail in error, please 
notify the sender and destroy all copies of the transmittal. 

Thank you
University of Chicago Medicine and Biological Sciences 
********************************************************************************

Re: Question regarding ntpd

[Sullivan, Daniel [CRI]]

Ok, this is bring clarity to the confusion.  I appreciate you taking the time to provide a thoughtful and detailed reply.

Dan

> On Sep 27, 2016, at 6:16 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> 
> On Tuesday, September 27, 2016 10:05:31 PM EDT Sullivan, Daniel [CRI] wrote:
>> type=SYSCALL msg=audit(1475012495.972:5327): arch=c000003e syscall=159
>> success=yes exit=0 a0=7ffd7498eb00 a1=861 a2=0 a3=1 items=0 ppid=1 pid=5357
>> auid=4294967295 uid=38 gid=38 euid=38 suid=38 fsuid=38 egid=38 sgid=38
>> fsgid=38 tty=(none) ses=4294967295 comm="ntpd" exe="/usr/sbin/ntpd"
>> key="time-change”
>> 
>> This is generating large amounts of log data.
> 
> Yep.
> 
>> I am not an expert in auditd log analysis.  Is this expected behavior? 
> 
> Unfortunately for that syscall yes. Your best option is to not audit that 
> syscall.
> 
> 
>> I am unsure of what the key time-change value of this log data is, and am
>> wondering if this indicates some sort of misconfiguration or problem with
>> ntpd.
> 
> Keys are used for reporting. You can run 
> aureport --start today --key --summary
> to get an idea of what kinds of events you are getting. You can also use keys 
> with ausearch to extract events that trigger on a specific rule and then feed 
> that to aureport.
> 
> 
>> From looking at the output of tcpdump it does not look like I am polling
>> every second, so I am wondering why this activity is occurring.   If anybody
>> could advise on how to decipher these log entries I would appreciate it. 
>> Thank you for your help and advisement.
> 
> Well, using the -i option to ausearch gives more meaning:
> 
> type=SYSCALL msg=audit(09/27/2016 17:41:35.972:5327) : arch=x86_64 
> syscall=adjtimex success=yes exit=0 a0=0x7ffd7498eb00 a1=0x861 a2=0x0 a3=0x1 
> items=0 ppid=1 pid=5357 auid=unset uid=ntp gid=ntp euid=ntp suid=ntp fsuid=ntp 
> egid=ntp sgid=ntp fsgid=ntp tty=(none) ses=unset comm=ntpd exe=/usr/sbin/ntpd 
> key=time-change
> 
> But the syscall uses a single data struct and we have no visibility into that 
> so we cannot tell any more what its doing.
> 
> The whole point of monitoring the time settings is that someone could tamper 
> with logs or cause something to appear like it occurred at a different time 
> than it really did. So, the idea is to collect this info "in case". But ntpd 
> overwhelms logs but chronyd might be marginally better. See bz
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=918127
> 
> for some discussion.
> 
> -Steve


********************************************************************************
This e-mail is intended only for the use of the individual or entity to which
it is addressed and may contain information that is privileged and confidential.
If the reader of this e-mail message is not the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this
communication is prohibited. If you have received this e-mail in error, please 
notify the sender and destroy all copies of the transmittal. 

Thank you
University of Chicago Medicine and Biological Sciences 
********************************************************************************

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: Question regarding ntpd

[L. A. Walsh]

Steve Grubb wrote:
> But ntpd overwhelms logs but chronyd might be marginally better. See bz
> https://bugzilla.redhat.com/show_bug.cgi?id=918127
>   
---
I took a gander at said bugzilla num, and found a minor surprise in that 
there
Miroslav Lichvar said:

   "You can use ntpd from the ntp package instead of chrony, it 
    shouldn't call adjtimex as often as chronyd does."
---


I.e. the exact opposite of your (Steve)'s statement.  Wondered if that was
a misread or newer information...<*idle curiosity*>.

Either way sounds like it would be "nice" to differentiate a "read" from
a "write" in this syscall if it is to be useful.

-l

Re: Question regarding ntpd

[Steve Grubb]

On Monday, October 10, 2016 2:48:23 PM EDT L. A. Walsh wrote:
> Steve Grubb wrote:
> > But ntpd overwhelms logs but chronyd might be marginally better. See bz
> > https://bugzilla.redhat.com/show_bug.cgi?id=918127
> 
> ---
> I took a gander at said bugzilla num, and found a minor surprise in that
> there
> Miroslav Lichvar said:
> 
>    "You can use ntpd from the ntp package instead of chrony, it
>     shouldn't call adjtimex as often as chronyd does."
> ---
> 
> I.e. the exact opposite of your (Steve)'s statement.  Wondered if that was
> a misread or newer information...<*idle curiosity*>.
> 
> Either way sounds like it would be "nice" to differentiate a "read" from
> a "write" in this syscall if it is to be useful.

I agree. But the problem with this syscall is that the operation is part of a 
data structure that is passed by address to the kernel. There currently is no 
good way to filter its uses because the audit subsystem can only look at the 
actual argument passed. I think there may be an issue opened for this on 
github.

-Steve

Re: Question regarding ntpd

[Paul Moore]

On Tue, Oct 11, 2016 at 12:07 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Monday, October 10, 2016 2:48:23 PM EDT L. A. Walsh wrote:
>> Steve Grubb wrote:
>> > But ntpd overwhelms logs but chronyd might be marginally better. See bz
>> > https://bugzilla.redhat.com/show_bug.cgi?id=918127
>>
>> ---
>> I took a gander at said bugzilla num, and found a minor surprise in that
>> there
>> Miroslav Lichvar said:
>>
>>    "You can use ntpd from the ntp package instead of chrony, it
>>     shouldn't call adjtimex as often as chronyd does."
>> ---
>>
>> I.e. the exact opposite of your (Steve)'s statement.  Wondered if that was
>> a misread or newer information...<*idle curiosity*>.
>>
>> Either way sounds like it would be "nice" to differentiate a "read" from
>> a "write" in this syscall if it is to be useful.
>
> I agree. But the problem with this syscall is that the operation is part of a
> data structure that is passed by address to the kernel. There currently is no
> good way to filter its uses because the audit subsystem can only look at the
> actual argument passed. I think there may be an issue opened for this on
> github.

Yep, link below:

* https://github.com/linux-audit/audit-kernel/issues/10

-- 
paul moore
www.paul-moore.com

Re: Question regarding ntpd

[L. A. Walsh]

Paul Moore wrote:
> On Tue, Oct 11, 2016 at 12:07 PM, Steve Grubb <sgrubb@redhat.com> wrote:
>   
>> On Monday, October 10, 2016 2:48:23 PM EDT L. A. Walsh wrote:
>>
>> I.e. the exact opposite of your (Steve)'s statement.  Wondered if that was
>> a misread or newer information...<*idle curiosity*>.
>>
>> Either way sounds like it would be "nice" to differentiate a "read" from
>> a "write" in this syscall if it is to be useful.
>>     
>> I agree. But the problem with this syscall is that the operation 
>> is part of a data structure that is passed by address to the kernel. 
>> There currently is no good way to filter its uses because the audit subsystem can only look at the actual argument passed. I think there 
>> may be an issue opened for this on github.
>>     
>
> Yep, link below:
>
> * https://github.com/linux-audit/audit-kernel/issues/10
>
>   
A parallel that may be useful -- the "file" program that ID's files, 
can't just
look at the value of a field, but values pointed-to, by-a-field.
Without the ability to record the value of a "pointer", I'd think audit was
a bit hamstrung.  At the destination of the pointer, one might want to 
support
other data types than just 'value' (usernames, groupnames, 
structures...etc).
Sad, but one might want to record an array of groups pointed to by some 
field
as well. 

Is it the case that nothing else in audit needs indirect information?

But as long as the data structure is defined by the kernel, I'd think it
a valid object to be able to audit...but that's my wanting flexibility.

Even wireshark/network monitoring needed to have the ability to compile
the filter into the kernel to create satifactory performance.  Might not 
audit
need similar?

Re: Question regarding ntpd

[Paul Moore]

On Tue, Oct 11, 2016 at 5:37 PM, L. A. Walsh <lkml@tlinx.org> wrote:
> Paul Moore wrote:
>>
>> On Tue, Oct 11, 2016 at 12:07 PM, Steve Grubb <sgrubb@redhat.com> wrote:
>>
>>>
>>> On Monday, October 10, 2016 2:48:23 PM EDT L. A. Walsh wrote:
>>>
>>> I.e. the exact opposite of your (Steve)'s statement.  Wondered if that
>>> was
>>> a misread or newer information...<*idle curiosity*>.
>>>
>>> Either way sounds like it would be "nice" to differentiate a "read" from
>>> a "write" in this syscall if it is to be useful.
>>>     I agree. But the problem with this syscall is that the operation is
>>> part of a data structure that is passed by address to the kernel. There
>>> currently is no good way to filter its uses because the audit subsystem can
>>> only look at the actual argument passed. I think there may be an issue
>>> opened for this on github.
>>
>> Yep, link below:
>>
>> * https://github.com/linux-audit/audit-kernel/issues/10
>>
>
> A parallel that may be useful -- the "file" program that ID's files, can't
> just
> look at the value of a field, but values pointed-to, by-a-field.
> Without the ability to record the value of a "pointer", I'd think audit was
> a bit hamstrung.  At the destination of the pointer, one might want to
> support
> other data types than just 'value' (usernames, groupnames,
> structures...etc).
> Sad, but one might want to record an array of groups pointed to by some
> field
> as well.
> Is it the case that nothing else in audit needs indirect information?
>
> But as long as the data structure is defined by the kernel, I'd think it
> a valid object to be able to audit...but that's my wanting flexibility.
>
> Even wireshark/network monitoring needed to have the ability to compile
> the filter into the kernel to create satifactory performance.  Might not
> audit
> need similar?

In order to provide the desired audit granularity for the adjtimex()
syscall we would need to add some additional audit hooks to that
syscall.  I've yet to see a good way of inspecting non-scalar objects
in a generic manner, we need to handle it on a case-by-case basis.

-- 
paul moore
www.paul-moore.com

Re: Question regarding ntpd

[Ryan Sawhill]

[-- Attachment #1.1: Type: text/plain, Size: 401 bytes --]

Also perhaps relevant is that the latest audit package in Fedora 24 even
has:

~]# cat /usr/share/doc/audit/rules/22-ignore-chrony.rules
> ## This rule suppresses the time-change event when chrony does time updates
> -a never,exit -F arch=b64 -S adjtimex -F auid=unset -Fuid=chrony -F
> subj_type=chronyd_t
> -a never,exit -F arch=b32 -S adjtimex -F auid=unset -Fuid=chrony -F
> subj_type=chronyd_t
>

[-- Attachment #1.2: Type: text/html, Size: 580 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]