On 2017-02-09 10:52, Steve Grubb wrote:
On Thursday, February 9, 2017 10:49:08 AM EST Richard Guy Briggs
wrote:
> On 2017-02-09 09:50, Steve Grubb wrote:
> > On Thursday, February 9, 2017 9:06:57 AM EST Richard Guy Briggs wrote:
> > > On 2017-01-13 10:48, Steve Grubb wrote:
> > > > On Friday, January 13, 2017 3:26:29 AM EST Richard Guy Briggs wrote:
> > > > > An AUDIT_SET message with the AUDIT_STATUS_LOST flag set by
itself
> > > > > will return a positive value repesenting the current audit_lost
> > > > > value and reset the counter to zero. If AUDIT_STATUS_LOST is
not
> > > > > the only flag set, the reset command will be ignored. The value
sent
> > > > > with the command is ignored. The return value will be the +ve
lost
> > > > > value at reset time.
> > > > >
> > > > > An AUDIT_CONFIG_CHANGE message will be queued to the listening
audit
> > > > > daemon. The message will be a standard CONFIG_CHANGE message
with
> > > > > the fields "lost=0" and "old=" with the
latter containing the value
> > > > > of audit_lost at reset time.
> > > >
> > > > This passes testing and event looks good.
> > >
> > > Did you create a formal test for it or just test it manually?
> >
> > I tested this by building a kernel and testing it by hand.
>
> Ok, this probably deserves a formal audit-testsuite case. What's the
> exact format of the reset command?
auditctl --reset-lost
Ok, no wonder I couldn't find it. This is backwards from what I
proposed in the wiki RFE, so I'll update it...
https://github.com/linux-audit/audit-kernel/wiki/RFE-Reset-the-Lost-Recor...
But even that doesn't appear to work. When I supply that option, I get
the help text which lists that option (with an extra space before the description).
-Steve
- RGB
--
Richard Guy Briggs <rgb(a)redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635