>> Because I was getting errors restarting the auditd on some of their
>> recommendations one of which was mount?
>Yes, that is correct. Mount is syscall 165 on x86_64 and 21 on i386.
-a exit,always -S mount fails on auditd restart
>> I would like to be able to do the audit log extractions (ausearch and
>> aureport) when I get say 8 - 20 megs logs. I see I can do an exec on a
>> script in max_log_file_action.
>> So if I set the max_log_file to 160, I can then run a script to move the
>> rotated logs and process them, thus not stopping auditd and keeping things
>> working?
>Yes, I think so. But if you are hooking max_log_file action, then you would
>need to send sigusr1 to ppid to get auditd to rotate the log and open another
>one. If you don't, auditd will still have an open descriptor to the file.
I am in error, I meant space_left_action because there is an exec for this.
I was going to do the "service auditd rotate" then move all the audit.log.* to
another directory so that ausearch -i and aureport -i could run on the logs.
The core for me is to keep audit running while dealing with log generation.
Our regression test can generate 8 20 meg rotated logs in an hour. So if I can
get audit to kick off the extraction script at certain points then that would
fix my situation.
Thanks.
David Flatley CISSP
Steve Grubb ---08/17/2009 11:08:40 AM---On Monday 17 August 2009 10:49:55 am David Flatley wrote: > If I were to move all the rotated logs
From: |
Steve Grubb <sgrubb@redhat.com> |
To: |
David Flatley/Burlington/IBM@IBMUS |
Cc: |
linux-audit@redhat.com |
Date: |
08/17/2009 11:08 AM |
Subject: |
Re: buffer space |
On Monday 17 August 2009 10:49:55 am David Flatley wrote:
> If I were to move all the rotated logs to another directory,
> say /home/logs. So instead of doing "ausearch -i" to capture all the
> information in the rotated logs in
> /var/log/audit directory. I would do "ausearch -i -f /home/logs" , correct?
Yes.
> Backlog is set to 12288 right now.
ok
> The SECSCAN requires many -w (watches) and a fair amount of syscalls. I
> modified the syscalls to add your recommendation for using "arch=b32" and
> "arch=b64".
Are there any public references to this standard?
> Because I was getting errors restarting the auditd on some of their
> recommendations one of which was mount?
Yes, that is correct. Mount is syscall 165 on x86_64 and 21 on i386.
> Another setting I believe was doing me in was the log size is 20 megs and
> I allow 8 rotated logs. But I had admin_disk_full set to 160 and the action
> was suspend.
> So this could have been tripping me up also.
If the partition was 320Mb or smaller, then yes that would be a problem. But I
also think the fact that its being suspended is sent to syslog.
> I would like to be able to do the audit log extractions (ausearch and
> aureport) when I get say 8 - 20 megs logs. I see I can do an exec on a
> script in max_log_file_action.
> So if I set the max_log_file to 160, I can then run a script to move the
> rotated logs and process them, thus not stopping auditd and keeping things
> working?
Yes, I think so. But if you are hooking max_log_file action, then you would
need to send sigusr1 to ppid to get auditd to rotate the log and open another
one. If you don't, auditd will still have an open descriptor to the file.
-Steve