On Tuesday, January 26, 2021 6:53:31 AM EST Burn Alting wrote:
On Tue, 2021-01-26 at 11:29 +1100, Burn Alting wrote:
On Mon, 2021-01-25 at 19:20 -0500, Steve Grubb wrote:
On Monday, January 25, 2021 7:11:45 PM EST Burn Alting wrote:
On Mon, 2021-01-25 at 18:53 -0500, Steve Grubb wrote:
On Saturday, January 23, 2021 5:55:44 PM EST Burn Alting wrote:
How is the following for a way forward.a. I will author a
patch to the
user space code to correctly parsethiscondition and submit it
on the
weekend. It will be via a newconfiguration item to
auditd.conf just in
case placing a fixedextended timeout (15-20 secs) affects
memory usage
for users of theauparse library. This solves the initial
problem
ofausearch/auparsefailing to parse generated audit.b. I am
happy to
instrument whateveris recommended on my hosts at home (vm's
and bare
metal) to providemore information, should we want to
'explain' the
occurrence, givenIsee this every week or two and report back.
Seems reasonable to me.
I can implement the 'end_of_event_timeout' change either asi. a
command
line argument to ausearch/aureport (say --eoetmo secs) andanew
pair of
library functions within the auparse() stable
(sayauparse_set_eoe_timeout() and auparse_get_eoe_timeout())orii.
a
configuration item in /etc/audit/auditd.conf, or
Which is your preference? Mine is i. as this is a user space
processingchange, not a demon change.
To be honest, I'm not entirely sure what we're seeing. I run some
teststoday on my system. It's seeing issues also. I'd still like
to treat theroot cause of this. But we do need to change the
default. That I whatI'm trying to figure out.
Back to your question, I'm wondering if we should do both? A
changeabledefault in auditd.conf and an override on the command
line.
So far, all items in /etc/audit/auditd.conf appear to only affect
thedaemon. Is this the right location to start adding
non-daemonconfiguration items? (I accept there is no other place).
ausearch/report/auparse all read the auditd.conf to find the canonical
location for where the logs are supposed to be. So, they already read
this file. I'd rather keep it there than make yet another config. The
only drawback it that it might again confuse people that auditd really
doesn't do anything with the records but just some light processing.
OK. I will put it in /etc/audit/auditd.conf
One question with this solution. If the user does not have read permission
to /etc/audit/auditd.conf, then any change cannot take effect. The default
mode for this file is 640 to root, so a non-root user could never change
the timeout.
Right, but since they cannot access the logs, it's not a problem in general.
But if they so happen to have a local copy of logs, then the command line
override should allow them to correct this. I am also reviewing things to see
if a better default can be picked.
Should I also add - a command line argument to ausearch/aureport (say --
eoetmo secs) and, - a pair of new auparse() functions -
auparse_set_eoe_timeout() and auparse_get_eoe_timeout()
so that non root users can make use of the new configuration item.
Yes, that is what I meant by doing both. We have default in auditd.conf that
works for everyone with direct audit access. We have a commandline option for
overriding the auditd.conf value.
Although, I don't know why we would want to get the eoe_timeout value? I
can't imagine a use for it right now.
As for ausearch/report, let's just make a long option --eoe-timeout
-Steve
Also, do you want the default timeout to be 2 seconds or should I make it
higher.
I'm likely to adjust it, but I'm still looking to see what is happening. Just
go with the 2 second default for now.
Issued PR just now.