<html dir="ltr"><head></head><body style="text-align:left; direction:ltr;"><div>All,</div><div><br></div><div>How is the following for a way forward.</div><div><br></div><div>a. I will author a patch to the user space code to correctly parse this condition and submit it on the weekend. It will be via a new configuration item to auditd.conf just in case placing a fixed extended timeout (15-20 secs) affects memory usage for users of the auparse library. This solves the initial problem of ausearch/auparse failing to parse generated audit.</div><div>b. I am happy to instrument what ever is recommended on my hosts at home (vm's and bare metal) to provide more information, should we want to 'explain' the occurrence, given I see this every week or two and report back.</div><div><br></div><div>On Tue, 2021-01-19 at 16:51 -0500, Steve Grubb wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>On Tuesday, January 19, 2021 3:26:04 PM EST Paul Moore wrote:</pre><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>On Tue, Jan 19, 2021 at 2:38 PM Burn Alting <</pre><a href="mailto:burn.alting@iinet.net.au"><pre>burn.alting@iinet.net.au</pre></a><pre>> </pre></blockquote><pre>wrote:</pre><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>All systems use chrony (current NTP daemon). One is a VM (on top of KVM)</pre><pre>and the other a bare metal deployment. Does the above explain my second</pre><pre>data set (in the issue) from a bare metal Centos 8 host? Perhaps Lenny's</pre><pre>comments bare investigation. Either way, I will offer a patch to the</pre><pre>user space code to, based on a configuration value, manage correctly</pre><pre>such activity.</pre></blockquote><pre>...</pre><pre><br></pre><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>msg=audit(1609920994.483:1787848):</pre><pre>msg=audit(1609920994.483:1787848):</pre><pre>msg=audit(1609920994.483:1787848):</pre><pre>msg=audit(1609920994.483:1787848):</pre><pre>msg=audit(1609920994.483:1787848):</pre><pre>msg=audit(1609920994.484:1787849):</pre><pre>msg=audit(1609920994.484:1787849):</pre><pre>msg=audit(1609921000.636:1787850):</pre><pre>msg=audit(1609921000.636:1787850):</pre><pre>msg=audit(1609921000.636:1787850):</pre><pre>msg=audit(1609921008.456:1787851):</pre><pre>msg=audit(1609921008.456:1787851):</pre><pre>msg=audit(1609921008.456:1787851):</pre><pre>msg=audit(1609921008.456:1787851):</pre><pre>msg=audit(1609921008.456:1787851):</pre><pre>msg=audit(1609921008.456:1787851):</pre><pre>msg=audit(1609920994.484:1787849):</pre><pre>msg=audit(1609920994.484:1787849):</pre><pre>msg=audit(1609920994.484:1787849):</pre><pre>msg=audit(1609921010.837:1787852):</pre><pre>msg=audit(1609921010.837:1787852):</pre><pre>msg=audit(1609921010.837:1787852):</pre></blockquote><pre><br></pre><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>msg=audit(1609921010.837:1787852):</pre></blockquote><pre>Looking at the extracted snippet above where event 1787849 is out of</pre><pre><br></pre><pre>order we see the following timestamps:</pre><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>msg=audit(1609920994.483:1787848):</pre><pre>msg=audit(1609920994.484:1787849):</pre><pre>msg=audit(1609921000.636:1787850):</pre><pre>msg=audit(1609921008.456:1787851):</pre></blockquote><pre><br></pre><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>msg=audit(1609921010.837:1787852):</pre></blockquote><pre><br></pre><pre>... which looks correct in as much that the time doesn't appear to go</pre><pre>backwards between events. As I said before, I'm not sure how Steve's</pre><pre>userspace works so the time may be a red herring.</pre></blockquote><pre><br></pre><pre>It only handles one record at a time. No chance to mix things up.</pre><pre><br></pre><pre>The github issue says that 30-stig.rules is being used. If the system time </pre><pre>changed with chrony, I would expect syscall events with adjtimex. But the </pre><pre>only ones given are execve.</pre><pre><br></pre><pre>-Steve</pre><pre><br></pre><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>Barring some weird condition where auditd disconnects and quickly</pre><pre>reconnects to the kernel, and/or dies and is replaced quickly, I'm not</pre><pre>seeing anything obvious in the kernel which would cause this. I'm not</pre><pre>saying there isn't anything there, just that it isn't obvious to me at</pre><pre>the moment :)</pre></blockquote><pre><br></pre><pre><br></pre><pre><br></pre><pre><br></pre></blockquote></body></html>