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.

On Sep 27, 2016, at 7:06 PM, John Jasen <jjasen(a)gmail.com&gt; 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(a)redhat.com > https://www.redhat.com/mailman/listinfo/linux-audit -- Linux-audit mailing list Linux-audit(a)redhat.com https://www.redhat.com/mailman/listinfo/linux-audit

But ntpd overwhelms logs but chronyd might be marginally better. See bz https://bugzilla.redhat.com/show_bug.cgi?id=918127

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.

Paul Moore wrote: > > On Tue, Oct 11, 2016 at 12:07 PM, Steve Grubb <sgrubb(a)redhat.com&gt; 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?