From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Flatley Subject: buffer space Date: Thu, 13 Aug 2009 10:56:50 -0400 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0716967862==" Return-path: Received: from mx3.redhat.com (mx3.redhat.com [172.16.48.32]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n7DEv7cl020908 for ; Thu, 13 Aug 2009 10:57:07 -0400 Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by mx3.redhat.com (8.13.8/8.13.8) with ESMTP id n7DEupIV031430 for ; Thu, 13 Aug 2009 10:56:51 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n7DEn0cq028025 for ; Thu, 13 Aug 2009 10:49:00 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n7DEup9M226774 for ; Thu, 13 Aug 2009 10:56:51 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n7DEs1IJ025841 for ; Thu, 13 Aug 2009 10:54:01 -0400 Received: from d01ml253.pok.ibm.com (d01ml253.pok.ibm.com [9.56.227.127]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n7DEs1sI025833 for ; Thu, 13 Aug 2009 10:54:01 -0400 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Linux-audit@redhat.com List-Id: linux-audit@redhat.com --===============0716967862== Content-type: multipart/alternative; Boundary="0__=0ABBFC82DFDCE5DD8f9e8a93df938690918c0ABBFC82DFDCE5DD" Content-Disposition: inline --0__=0ABBFC82DFDCE5DD8f9e8a93df938690918c0ABBFC82DFDCE5DD Content-type: text/plain; charset=US-ASCII Red Hat 5.3 running audit 1.7.7-6 Rotating logs at 20 megs and allowing 8 logs Rules have watches and syscalls from the SECSCAN recommendations, and have added some of Steve Grubb's recommendations. When we extract and archive the audit logs we get "Error receiving audit netlink packet (No buffer space available) an "error sending signal info request" Our extract is: stop auditd then create a file and run ausearch -i > file then run an aureport -i > file then once that is done we delete all the logs and restart auditd. If I run this manually it works fine but if I have it running it in a cron we get Kernel panics, lockups and log data loss plus the buffer messages. I added "-r 0" to the audit.rules but it does not seem to work. We run a very similar configuration on Red Hat ES and AS 4 with no problems. We are testing the subject systems and running a looping regression test that can fill the audit logs in a little over an hour at the present settings. Thoughts or ideas?? Thanks. David Flatley CISSP I.T. Specialist, Managing Consultant Member: ISC2, ISACA, Center for Internet Security --0__=0ABBFC82DFDCE5DD8f9e8a93df938690918c0ABBFC82DFDCE5DD Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Red Hat 5.3 running audit 1.7.7-6
Rotating logs at 20 megs and allowing 8 logs
Rules have watches and syscalls from the SECSCAN recommendations, and have added some of Steve Grubb's recommendations.
When we extract and archive the audit logs we get "Error receiving audit netlink packet (No buffer space available) an "error sending signal info request"
Our extract is: stop auditd then create a file and run ausearch -i > file then run an aureport -i > file then once that is done we delete all the logs and restart auditd.
If I run this manually it works fine but if I have it running it in a cron we get Kernel panics, lockups and log data loss plus the buffer messages.
I added "-r 0" to the audit.rules but it does not seem to work. We run a very similar configuration on Red Hat ES and AS 4 with no problems.
We are testing the subject systems and running a looping regression test that can fill the audit logs in a little over an hour at the present settings.
Thoughts or ideas??
Thanks.

David Flatley CISSP
I.T. Specialist, Managing Consultant
Member: ISC2, ISACA, Center for Internet Security


--0__=0ABBFC82DFDCE5DD8f9e8a93df938690918c0ABBFC82DFDCE5DD-- --===============0716967862== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============0716967862==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Booth Subject: Re: buffer space Date: Thu, 13 Aug 2009 16:29:02 +0100 Message-ID: <4A84313E.3010809@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: David Flatley Cc: Linux-audit@redhat.com List-Id: linux-audit@redhat.com On 13/08/09 15:56, David Flatley wrote: > Red Hat 5.3 running audit 1.7.7-6 > Rotating logs at 20 megs and allowing 8 logs > Rules have watches and syscalls from the SECSCAN recommendations, and > have added some of Steve Grubb's recommendations. > When we extract and archive the audit logs we get "Error receiving audit > netlink packet (No buffer space available) an "error sending signal info > request" Where do you get these messages? Are they in /var/log/messages? > Our extract is: stop auditd then create a file and run ausearch -i > > file then run an aureport -i > file then once that is done we delete all > the logs and restart auditd. You don't want to be stopping auditd. I'd either look harder into the command line arguments to ausearch and aureport and combine ussage with 'service auditd rotate', or use a different collection mechanism. Also, how are you stopping auditd? Are you using 'service auditd stop'? If so, you are losing data because it removes audit rules when it stops. If you are using somethine else like SIGSTOP, the kernel is sensitive to the audit daemon not being responsive. This is likely to cause problems. Can you post the exact script you're using? Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: buffer space Date: Thu, 13 Aug 2009 14:28:43 -0400 Message-ID: <200908131428.52924.sgrubb@redhat.com> References: Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Thursday 13 August 2009 10:56:50 am David Flatley wrote: > Red Hat 5.3 running audit 1.7.7-6 > Rotating logs at 20 megs and allowing 8 logs > Rules have watches and syscalls from the SECSCAN recommendations, and have > added some of Steve Grubb's recommendations. I would be curious what the SECSCAN recommendations are. Never heard of it... > When we extract and archive the audit logs we get "Error receiving audit > netlink packet (No buffer space available) an "error sending signal info > request" > Our extract is: stop auditd then create a file and run ausearch -i > file > then run an aureport -i > file then once that is done we delete all the > logs and restart auditd. I think this is your problem. If you have audit rules loaded and stop auditd, then audit events are going to pile up in the queue waiting for auditd to download them. At some point the kernel will decide auditd doesn't exist and will dump all events to syslog. This probably is not what you want either. I would recommend calling "service auditd rotate" and then grab logs audit.log.1 -> audit.logs.7 and move them away to another directory for post processing the contents. You may also want to check you backlog size settings too. > If I run this manually it works fine but if I have it running it in a cron > we get Kernel panics, lockups and log data loss plus the buffer messages. Shouldn't really make a difference. -Steve From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Flatley Subject: Re: buffer space Date: Mon, 17 Aug 2009 10:49:55 -0400 Message-ID: References: <200908131428.52924.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1882421371==" Return-path: In-Reply-To: <200908131428.52924.sgrubb@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com --===============1882421371== Content-type: multipart/related; Boundary="0__=0ABBFC86DFDDC0D48f9e8a93df938690918c0ABBFC86DFDDC0D4" --0__=0ABBFC86DFDDC0D48f9e8a93df938690918c0ABBFC86DFDDC0D4 Content-type: multipart/alternative; Boundary="1__=0ABBFC86DFDDC0D48f9e8a93df938690918c0ABBFC86DFDDC0D4" --1__=0ABBFC86DFDDC0D48f9e8a93df938690918c0ABBFC86DFDDC0D4 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Thanks Steve! 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" , corr= ect? Backlog is set to 12288 right now. The SECSCAN requires many -w (watches) and a fair amount of syscalls. = I modified the syscalls to add your recommendation for using "arch=3Db32"= and "arch=3Db64". Because I was getting errors restarting the auditd on some of their recommendations one of which was mount? 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 ac= tion was suspend. So this could have been tripping me up also. 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 th= e rotated logs and process them, thus not stopping auditd and keeping thi= ngs working? I would set the max rotated logs to 10 to allow the new rotated log space then move the= logs as you suggest. Thanks. David Flatley CISSP = = From: Steve Grubb = = = = To: linux-audit@redhat.com = = = = Cc: David Flatley/Burlington/IBM@IBMUS = = = = Date: 08/13/2009 02:29 PM = = = = Subject: Re: buffer space = = = = On Thursday 13 August 2009 10:56:50 am David Flatley wrote: > Red Hat 5.3 running audit 1.7.7-6 > Rotating logs at 20 megs and allowing 8 logs > Rules have watches and syscalls from the SECSCAN recommendations, and= have > added some of Steve Grubb's recommendations. I would be curious what the SECSCAN recommendations are. Never heard of= it... > When we extract and archive the audit logs we get "Error receiving au= dit > netlink packet (No buffer space available) an "error sending signal i= nfo > request" > Our extract is: stop auditd then create a file and run ausearch -i > = file > then run an aureport -i > file then once that is done we delete all t= he > logs and restart auditd. I think this is your problem. If you have audit rules loaded and stop auditd, then audit events are going to pile up in the queue waiting for auditd = to download them. At some point the kernel will decide auditd doesn't exis= t and will dump all events to syslog. This probably is not what you want eith= er. I would recommend calling "service auditd rotate" and then grab logs audit.log.1 -> audit.logs.7 and move them away to another directory for= post processing the contents. You may also want to check you backlog size settings too. > If I run this manually it works fine but if I have it running it in a= cron > we get Kernel panics, lockups and log data loss plus the buffer messa= ges. Shouldn't really make a difference. -Steve = --1__=0ABBFC86DFDDC0D48f9e8a93df938690918c0ABBFC86DFDDC0D4 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Thanks Steve!
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 i= nformation in the rotated logs in
/var/log/audit directory. I would do "ausearch -i -f /home/logs&qu= ot; , correct?

Backlog is set to 12288 right now.

The SECSCAN requires many -w (watches) and a fair amount of syscalls. = I modified the syscalls to add your recommendation for using "arch= =3Db32" and "arch=3Db64".
Because I was getting errors restarting the auditd on some of their rec= ommendations one of which was mount?

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 th= e action was suspend.
So this could have been tripping me up also.

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 th= e rotated logs and process them, thus not stopping auditd and keeping t= hings working? I would set the
max rotated logs to 10 to allow the new rotated log space then move the= logs as you suggest.

Thanks.

David Flatley CISSP




3D"InactiveSteve Grubb ---08= /13/2009 02:29:34 PM---On Thursday 13 August 2009 10:56:50 am David Fla= tley wrote: > Red Hat 5.3 running audit 1.7.7-6

= =
3D=
From:
= 3D""
Steve Grubb <sgrubb@redhat.com>
3D=
To:

linux-audit@redhat.com
3D=
Cc:
3D""
David Flatley/Burlington/IBM@IBMUS
3D=
Date:
= 3D""
08/13/2009 02:29 PM
3D=
Subject:
3D""
Re: buffer space





On Thursday 13 August 2009 10:56:50 am David Flatley wrote:
>   Red Hat 5.3 running audit 1.7.7-6
> Rotating logs at 20 megs and allowing 8 logs
> Rules have watches and syscalls from the SECSCAN recommendations, = and have
> added some of Steve Grubb's recommendations.

I would be curious what the SECSCAN recommendations are. Never heard of= it...


> When we extract and archive the audit logs we get "Error rece= iving audit
> netlink packet (No buffer space available) an "error sending = signal info
> request"
> Our extract is: stop auditd then create a file and run ausearch -i= > file
> then run an aureport -i > file then once that is done we delete= all the
> logs and restart auditd.

I think this is your problem. If you have audit rules loaded and stop a= uditd,
then audit events are going to pile up in the queue waiting for auditd = to
download them. At some point the kernel will decide auditd doesn't exis= t and
will dump all events to syslog. This probably is not what you want eith= er.

I would recommend calling "service auditd rotate" and then gr= ab logs
audit.log.1 -> audit.logs.7 and move them away to another directory = for post  
processing the contents.

You may also want to check you backlog size settings too.


> If I run this manually it works fine but if I have it running it i= n a cron
> we get Kernel panics, lockups and log data loss plus the buffer me= ssages.

Shouldn't really make a difference.

-Steve


= --1__=0ABBFC86DFDDC0D48f9e8a93df938690918c0ABBFC86DFDDC0D4-- --0__=0ABBFC86DFDDC0D48f9e8a93df938690918c0ABBFC86DFDDC0D4 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABBFC86DFDDC0D48f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBFC86DFDDC0D48f9e8a93df938690918c0ABBFC86DFDDC0D4 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <2__=0ABBFC86DFDDC0D48f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBFC86DFDDC0D48f9e8a93df938690918c0ABBFC86DFDDC0D4-- --===============1882421371== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============1882421371==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: buffer space Date: Mon, 17 Aug 2009 11:07:52 -0400 Message-ID: <200908171108.00417.sgrubb@redhat.com> References: <200908131428.52924.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: David Flatley Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Norman Mark St. Laurent" Subject: Re: buffer space Date: Mon, 17 Aug 2009 11:34:28 -0400 Message-ID: <4A897884.6030703@conceras.com> References: <200908131428.52924.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mx3.redhat.com (mx3.redhat.com [172.16.48.32]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n7HFYjRq009490 for ; Mon, 17 Aug 2009 11:34:45 -0400 Received: from p3plsmtpa01-01.prod.phx3.secureserver.net (p3plsmtpa01-01.prod.phx3.secureserver.net [72.167.82.81]) by mx3.redhat.com (8.13.8/8.13.8) with SMTP id n7HFYUvN009146 for ; Mon, 17 Aug 2009 11:34:30 -0400 In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: David Flatley Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com Hi David, I too would like to know what version of SECSCAN you are using for the "required watches". I run the STIGS, SECSCAN, and a myriad of vulnerability analysis tools (outside looking in --> inside looking around) on systems that I ISSE and provision. I do not recall "required watches" that need to be set with this tool, but I maybe off a version and I may need to visit another sight to pick up the latest and greatest.... I know SECSCAN would like the System to be configured to HALT on audit failure using the disk_ful_action_setting in /etc/audit/auditd.conf. It would also like the system to be configured to halt on audit disk error as well as the audit data to be synchronously flushed to disk to avoid data loss. To do this (respectfully) I have set in my KickStarts and Satellite: perl -npe 's/disk_full_action = SUSPEND/disk_full_action = HALT/' -i /etc/audit/auditd.conf perl -npe 's/disk_error_action = SUSPEND/disk_error_action = HALT/' -i /etc/audit/auditd.conf perl -npe 's/flush = INCREMENTAL/flush = SYNC/' -i /etc/audit/auditd.conf Currently I set the /var/log/audit logs to rotate daily for 90 days... in /etc/logrotate.d/audit and the capp.rules ; nispom.rules in /usr/share/doc/audit* all work great and provide nice examples to comply with Security Policy. Because of the logrotation and the way aureport works, I have written a wrapper script to be able to search and report all the log files. Something of this type would help the Security Officers look threw the log files. The script also keeps a pristine copy of the log files for investigation with digital sigs to watch the tampering (as well as aide) for investigation if need be --> this keeps processing the files (MAC Times) and a pristine copy separated. I am very interested in finding our more about these set watches that are required in SECSCAN. Best regards, Norman Mark St. Laurent Conceras | Chief Technology Officer and ISSE David Flatley wrote: > > Thanks Steve! > 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? > > Backlog is set to 12288 right now. > > 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". > Because I was getting errors restarting the auditd on some of their > recommendations one of which was mount? > > 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. > > 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? I would set the > max rotated logs to 10 to allow the new rotated log space then move > the logs as you suggest. > > Thanks. > > David Flatley CISSP > > > > > Inactive hide details for Steve Grubb ---08/13/2009 02:29:34 PM---On > Thursday 13 August 2009 10:56:50 am David Flatley wrote: > Steve Grubb > ---08/13/2009 02:29:34 PM---On Thursday 13 August 2009 10:56:50 am > David Flatley wrote: > Red Hat 5.3 running audit 1.7.7-6 > > > From: > Steve Grubb > > To: > linux-audit@redhat.com > > Cc: > David Flatley/Burlington/IBM@IBMUS > > Date: > 08/13/2009 02:29 PM > > Subject: > Re: buffer space > > > > > On Thursday 13 August 2009 10:56:50 am David Flatley wrote: > > Red Hat 5.3 running audit 1.7.7-6 > > Rotating logs at 20 megs and allowing 8 logs > > Rules have watches and syscalls from the SECSCAN recommendations, > and have > > added some of Steve Grubb's recommendations. > > I would be curious what the SECSCAN recommendations are. Never heard > of it... > > > > When we extract and archive the audit logs we get "Error receiving audit > > netlink packet (No buffer space available) an "error sending signal info > > request" > > Our extract is: stop auditd then create a file and run ausearch -i > > file > > then run an aureport -i > file then once that is done we delete all the > > logs and restart auditd. > > I think this is your problem. If you have audit rules loaded and stop > auditd, > then audit events are going to pile up in the queue waiting for auditd to > download them. At some point the kernel will decide auditd doesn't > exist and > will dump all events to syslog. This probably is not what you want either. > > I would recommend calling "service auditd rotate" and then grab logs > audit.log.1 -> audit.logs.7 and move them away to another directory > for post > processing the contents. > > You may also want to check you backlog size settings too. > > > > If I run this manually it works fine but if I have it running it in > a cron > > we get Kernel panics, lockups and log data loss plus the buffer > messages. > > Shouldn't really make a difference. > > -Steve > > > ------------------------------------------------------------------------ > > -- > Linux-audit mailing list > Linux-audit@redhat.com > https://www.redhat.com/mailman/listinfo/linux-audit From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Norman Mark St. Laurent" Subject: Re: buffer space Date: Mon, 17 Aug 2009 11:36:42 -0400 Message-ID: <4A89790A.8070505@conceras.com> References: <200908131428.52924.sgrubb@redhat.com> <200908171108.00417.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mx3.redhat.com (mx3.redhat.com [172.16.48.32]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n7HFb1S4012020 for ; Mon, 17 Aug 2009 11:37:02 -0400 Received: from p3plsmtpa01-09.prod.phx3.secureserver.net (p3plsmtpa01-09.prod.phx3.secureserver.net [72.167.82.89]) by mx3.redhat.com (8.13.8/8.13.8) with SMTP id n7HFaiX5011019 for ; Mon, 17 Aug 2009 11:36:44 -0400 In-Reply-To: <200908171108.00417.sgrubb@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com Steve, I maybe able to get the Red Hat Federal Team a copy of SECSCAN... If Justin and Gunnar do not already have a copy.... Best regards, Norman Mark St. Laurent Conceras | Chief Technology Officer and ISSE Phone: 703-965-4892 Email: mstlaurent@conceras.com Web: http://www.conceras.com Connect. Collaborate. Conceras. Steve Grubb wrote: > 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 > > -- > Linux-audit mailing list > Linux-audit@redhat.com > https://www.redhat.com/mailman/listinfo/linux-audit > > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Flatley Subject: Re: buffer space Date: Mon, 17 Aug 2009 12:38:07 -0400 Message-ID: References: <200908131428.52924.sgrubb@redhat.com> <200908171108.00417.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0549730544==" Return-path: In-Reply-To: <200908171108.00417.sgrubb@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com --===============0549730544== Content-type: multipart/related; Boundary="0__=0ABBFC86DFCAEAF98f9e8a93df938690918c0ABBFC86DFCAEAF9" --0__=0ABBFC86DFCAEAF98f9e8a93df938690918c0ABBFC86DFCAEAF9 Content-type: multipart/alternative; Boundary="1__=0ABBFC86DFCAEAF98f9e8a93df938690918c0ABBFC86DFCAEAF9" --1__=0ABBFC86DFCAEAF98f9e8a93df938690918c0ABBFC86DFCAEAF9 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable >> 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 fi= le. 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.l= og.* 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 i= f I can get audit to kick off the extraction script at certain points then that= would fix my situation. Thanks. David Flatley CISSP = = From: Steve Grubb = = = = 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=3Db3= 2" and > "arch=3Db64". 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 meg= s 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 a= nd > 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 w= ould 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 fil= e. -Steve = --1__=0ABBFC86DFCAEAF98f9e8a93df938690918c0ABBFC86DFCAEAF9 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

>> Because I was getting errors restarting the auditd on s= ome 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 extract= ions (ausearch and
>> aureport) when I get say 8 - 20 megs logs. I see I can do an e= xec on a
>> script in max_log_file_action.
>> So if I set the max_log_file to 160, I can then run a script t= o move the
>> rotated logs and process them, thus not stopping auditd and ke= eping things
>> working?

>Yes, I think so. But if you are hooking max_log_file action, then y= ou would
>need to send sigusr1 to ppid to get auditd to rotate the log and op= en 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 f= or this.
I was going to do the "service auditd rotate" then move a= ll 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 gen= eration.
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




3D"InactiveSteve Grubb ---08= /17/2009 11:08:40 AM---On Monday 17 August 2009 10:49:55 am David Flatl= ey wrote: > If I were to move all the rotated logs

= =
3D=
From:
= 3D""
Steve Grubb <sgrubb@redhat.com>
3D=
To:

David Flatley/Burlington/IBM@IBMUS
3D=
Cc:
3D""
linux-audit@redhat.com
3D=
Date:
= 3D""
08/17/2009 11:08 AM
3D=
Subject:
3D""
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 cap= ture all the
> information in the rotated logs in
> /var/log/audit directory. I would do "ausearch -i -f /home/lo= gs" , 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 "a= rch=3Db32" and
> "arch=3Db64".

Are there any public references to this standard?


> Because I was getting errors restarting the auditd on some of thei= r
> 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 i= s 20 megs and
> I allow 8 rotated logs. But I had admin_disk_full set to 160 and t= he 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 (au= search 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 mo= ve the
> rotated logs and process them, thus not stopping auditd and keepin= g things
> working?

Yes, I think so. But if you are hooking max_log_file action, then you w= ould
need to send sigusr1 to ppid to get auditd to rotate the log and open a= nother
one. If you don't, auditd will still have an open descriptor to the fil= e.

-Steve


= --1__=0ABBFC86DFCAEAF98f9e8a93df938690918c0ABBFC86DFCAEAF9-- --0__=0ABBFC86DFCAEAF98f9e8a93df938690918c0ABBFC86DFCAEAF9 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABBFC86DFCAEAF98f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBFC86DFCAEAF98f9e8a93df938690918c0ABBFC86DFCAEAF9 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <2__=0ABBFC86DFCAEAF98f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBFC86DFCAEAF98f9e8a93df938690918c0ABBFC86DFCAEAF9-- --===============0549730544== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============0549730544==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: LC Bruzenak Subject: Re: buffer space Date: Mon, 17 Aug 2009 11:52:52 -0500 Message-ID: <1250527972.3048.693.camel@homeserver> References: <200908131428.52924.sgrubb@redhat.com> <200908171108.00417.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: David Flatley Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Mon, 2009-08-17 at 12:38 -0400, David Flatley wrote:\ > > 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. David, I do not think this is entirely accurate. It is one of my own issues. I am doing the same type thing. This is necessary on a system with large amounts of audit data (as aggregated systems tend to be). I am also moving stuff out of the standard directory. However, IIUC, the ausearch options will only work on specific files. If you move the rotated files off to another directory you will lose the ability to search the directory with a single ausearch command. If there were a "-id" option (input directory, or similar) which allowed this I believe it would work better. Otherwise you could possibly cat the files into one large one, but this is not optimal IMHO. Steve recently patched the disk threshold code to auto-reset, which is nice. You probably want this; it sounds as if we are doing similar functions. I also have SECSCN issues/mitigations. LCB. -- LC (Lenny) Bruzenak lenny@magitekltd.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Nixon Subject: Re: buffer space Date: Mon, 17 Aug 2009 12:58:57 -0400 Message-ID: References: <200908131428.52924.sgrubb@redhat.com> <4A897884.6030703@conceras.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=00235407f00653dd7a047159511e Return-path: Received: from mx1.redhat.com (mx1.redhat.com [172.16.48.31]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n7HGxBIK010035 for ; Mon, 17 Aug 2009 12:59:11 -0400 Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n7HGwviL012814 for ; Mon, 17 Aug 2009 12:58:57 -0400 Received: by fxm28 with SMTP id 28so2424403fxm.41 for ; Mon, 17 Aug 2009 09:58:57 -0700 (PDT) In-Reply-To: <4A897884.6030703@conceras.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: "Norman Mark St. Laurent" Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com --00235407f00653dd7a047159511e Content-Type: multipart/alternative; boundary=00235407f00653dd71047159511c --00235407f00653dd71047159511c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Attached are is the audit.rules file from SECSCN 4.3. There is a v4.4 now available but I don't have it handy. Also attached are two docs which explain SECSCN's auditd configuration expectations. -Mike On Mon, Aug 17, 2009 at 11:34 AM, Norman Mark St. Laurent < mstlaurent@conceras.com> wrote: > Hi David, > > I too would like to know what version of SECSCAN you are using for the > "required watches". I run the STIGS, SECSCAN, and a myriad of vulnerability > analysis tools (outside looking in --> inside looking around) on systems > that I ISSE and provision. I do not recall "required watches" that need to > be set with this tool, but I maybe off a version and I may need to visit > another sight to pick up the latest and greatest.... > > I know SECSCAN would like the System to be configured to HALT on audit > failure using the disk_ful_action_setting in /etc/audit/auditd.conf. It > would also like the system to be configured to halt on audit disk error as > well as the audit data to be synchronously flushed to disk to avoid data > loss. To do this (respectfully) I have set in my KickStarts and Satellite: > > perl -npe 's/disk_full_action = SUSPEND/disk_full_action = HALT/' -i > /etc/audit/auditd.conf > perl -npe 's/disk_error_action = SUSPEND/disk_error_action = HALT/' -i > /etc/audit/auditd.conf > perl -npe 's/flush = INCREMENTAL/flush = SYNC/' -i /etc/audit/auditd.conf > > Currently I set the /var/log/audit logs to rotate daily for 90 days... in > /etc/logrotate.d/audit and the capp.rules ; nispom.rules in > /usr/share/doc/audit* all work great and provide nice examples to comply > with Security Policy. > > Because of the logrotation and the way aureport works, I have written a > wrapper script to be able to search and report all the log files. Something > of this type would help the Security Officers look threw the log files. The > script also keeps a pristine copy of the log files for investigation with > digital sigs to watch the tampering (as well as aide) for investigation if > need be --> this keeps processing the files (MAC Times) and a pristine copy > separated. > > I am very interested in finding our more about these set watches that are > required in SECSCAN. > > Best regards, > > > Norman Mark St. Laurent > Conceras | Chief Technology Officer and ISSE > > > > David Flatley wrote: > >> >> Thanks Steve! >> 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? >> >> Backlog is set to 12288 right now. >> >> 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". >> Because I was getting errors restarting the auditd on some of their >> recommendations one of which was mount? >> >> 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. >> >> 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? I would set the >> max rotated logs to 10 to allow the new rotated log space then move the >> logs as you suggest. >> >> Thanks. >> >> David Flatley CISSP >> >> >> >> >> Inactive hide details for Steve Grubb ---08/13/2009 02:29:34 PM---On >> Thursday 13 August 2009 10:56:50 am David Flatley wrote: > Steve Grubb >> ---08/13/2009 02:29:34 PM---On Thursday 13 August 2009 10:56:50 am David >> Flatley wrote: > Red Hat 5.3 running audit 1.7.7-6 >> >> >> From: >> Steve Grubb >> >> To: >> linux-audit@redhat.com >> >> Cc: >> David Flatley/Burlington/IBM@IBMUS >> >> Date: >> 08/13/2009 02:29 PM >> >> Subject: >> Re: buffer space >> >> >> >> >> On Thursday 13 August 2009 10:56:50 am David Flatley wrote: >> > Red Hat 5.3 running audit 1.7.7-6 >> > Rotating logs at 20 megs and allowing 8 logs >> > Rules have watches and syscalls from the SECSCAN recommendations, and >> have >> > added some of Steve Grubb's recommendations. >> >> I would be curious what the SECSCAN recommendations are. Never heard of >> it... >> >> >> > When we extract and archive the audit logs we get "Error receiving audit >> > netlink packet (No buffer space available) an "error sending signal info >> > request" >> > Our extract is: stop auditd then create a file and run ausearch -i > >> file >> > then run an aureport -i > file then once that is done we delete all the >> > logs and restart auditd. >> >> I think this is your problem. If you have audit rules loaded and stop >> auditd, >> then audit events are going to pile up in the queue waiting for auditd to >> download them. At some point the kernel will decide auditd doesn't exist >> and >> will dump all events to syslog. This probably is not what you want either. >> >> I would recommend calling "service auditd rotate" and then grab logs >> audit.log.1 -> audit.logs.7 and move them away to another directory for >> post processing the contents. >> >> You may also want to check you backlog size settings too. >> >> >> > If I run this manually it works fine but if I have it running it in a >> cron >> > we get Kernel panics, lockups and log data loss plus the buffer >> messages. >> >> Shouldn't really make a difference. >> >> -Steve >> >> >> ------------------------------------------------------------------------ >> >> -- >> Linux-audit mailing list >> Linux-audit@redhat.com >> https://www.redhat.com/mailman/listinfo/linux-audit >> > > -- > Linux-audit mailing list > Linux-audit@redhat.com > https://www.redhat.com/mailman/listinfo/linux-audit > --00235407f00653dd71047159511c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Attached are is the audit.rules file from SECSCN 4.3. =A0There is a v4.4 no= w available but I don't have it handy. =A0Also attached are two docs wh= ich explain SECSCN's auditd configuration expectations.=A0

= -Mike

On Mon, Aug 17, 2009 at 11:34 AM, Norma= n Mark St. Laurent <mstlaurent@conceras.com> wrote:
Hi David,

I too would like to know what version of SECSCAN you are using for the &quo= t;required watches". =A0I run the STIGS, SECSCAN, and a myriad of vuln= erability analysis tools (outside looking in --> =A0inside looking aroun= d) on systems that I ISSE and provision. =A0I do not recall "required = watches" that need to be set with this tool, but I maybe off a version= and I may need to visit another sight to pick up the latest and greatest..= ..

I know SECSCAN would like the System to be configured to HALT on audit fail= ure using the disk_ful_action_setting in /etc/audit/auditd.conf. =A0It woul= d also like the system to be configured to halt on audit disk error as well= as the audit data to be synchronously flushed to disk to avoid data loss. = =A0To do this (respectfully) I have set in my KickStarts and Satellite:

perl -npe 's/disk_full_action =3D SUSPEND/disk_full_action =3D HALT/= 9; -i /etc/audit/auditd.conf
perl -npe 's/disk_error_action =3D SUSPEND/disk_error_action =3D HALT/&= #39; -i /etc/audit/auditd.conf
perl -npe 's/flush =3D INCREMENTAL/flush =3D SYNC/' -i /etc/audit/a= uditd.conf

Currently I set the /var/log/audit logs to rotate daily for 90 days... =A0i= n /etc/logrotate.d/audit =A0and the capp.rules ; nispom.rules in /usr/share= /doc/audit* all work great and provide nice examples to comply with Securit= y Policy.

Because of the logrotation and the way aureport works, I have written a wra= pper script to be able to search and report all the log files. =A0Something= of this type would help the Security Officers look threw the log files. = =A0The script also keeps a pristine copy of the log files for investigation= with digital sigs to watch the tampering =A0(as well as aide) for investig= ation if need be --> this keeps processing the files (MAC Times) and a p= ristine copy separated.

I am very interested in finding our more about these set watches that are r= equired in SECSCAN.

Best regards,


Norman Mark St. Laurent
Conceras | Chief Technology Officer and ISSE



David Flatley wrote:

Thanks Steve!
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 informatio= n in the rotated logs in
/var/log/audit directory. I would do "ausearch -i -f /home/logs" = , correct?

Backlog is set to 12288 right now.

The SECSCAN requires many -w (watches) and a fair amount of syscalls. I mod= ified the syscalls to add your recommendation for using "arch=3Db32&qu= ot; and "arch=3Db64".
Because I was getting errors restarting the auditd on some of their recomme= ndations one of which was mount?

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.

I would like to be able to do the audit log extractions (ausearch and aurep= ort) 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 ro= tated logs and process them, thus not stopping auditd and keeping things wo= rking? I would set the
max rotated logs to 10 to allow the new rotated log space then move the log= s as you suggest.

Thanks.

David Flatley CISSP




Inactive hide details for Steve Grubb ---08/13/2009 02:29:34 PM---On Thursd= ay 13 August 2009 10:56:50 am David Flatley wrote: > Steve Grubb ---08/1= 3/2009 02:29:34 PM---On Thursday 13 August 2009 10:56:50 am David Flatley w= rote: > Red Hat 5.3 running audit 1.7.7-6


From: =A0
Steve Grubb <sgru= bb@redhat.com>

To: =A0 =A0
linux-audit@red= hat.com

Cc: =A0 =A0
David Flatley/Burlington/IBM@IBMUS

Date: =A0
08/13/2009 02:29 PM

Subject: =A0 =A0 =A0 =A0
Re: buffer space




On Thursday 13 August 2009 10:56:50 am David Flatley wrote:
> =A0 Red Hat 5.3 running audit 1.7.7-6
> Rotating logs at 20 megs and allowing 8 logs
> Rules have watches and syscalls from the SECSCAN recommendations, and = have
> added some of Steve Grubb's recommendations.

I would be curious what the SECSCAN recommendations are. Never heard of it.= ..


> When we extract and archive the audit logs we get "Error receivin= g audit
> netlink packet (No buffer space available) an "error sending sign= al info
> request"
> Our extract is: stop auditd then create a file and run ausearch -i >= ; file
> then run an aureport -i > file then once that is done we delete all= the
> logs and restart auditd.

I think this is your problem. If you have audit rules loaded and stop audit= d,
then audit events are going to pile up in the queue waiting for auditd to download them. At some point the kernel will decide auditd doesn't exis= t and
will dump all events to syslog. This probably is not what you want either.<= br>
I would recommend calling "service auditd rotate" and then grab l= ogs
audit.log.1 -> audit.logs.7 and move them away to another directory for = post =A0processing the contents.

You may also want to check you backlog size settings too.


> If I run this manually it works fine but if I have it running it in a = cron
> we get Kernel panics, lockups and log data loss plus the buffer messag= es.

Shouldn't really make a difference.

-Steve


------------------------------------------------------------------------

--
Linux-audit mailing list
Linux-audit@red= hat.com
https://www.redhat.com/mailman/listinfo/linux-audit

--00235407f00653dd71047159511c-- --00235407f00653dd7a047159511e Content-Type: text/html; charset=US-ASCII; name="AUDIT1.HTML" Content-Disposition: attachment; filename="AUDIT1.HTML" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fyhg9h8c1 PEhUTUw+CjxUSVRMRT5BdWRpdDE8L1RJVExFPgo8Qk9EWSBCR0NPTE9SPXdoaXRlPgoKPEgzPjxi PlByb3RlY3Rpb24gTGV2ZWwgMjwvYj48L0gzPgo8Yj5EQ0lEIDYvMyBSZXF1aXJlbWVudHMgLTwv Yj4KPEJSPjxCUj4KNC5CLjIuYSAgPGI+QSBzeXN0ZW0gb3BlcmF0aW5nIGF0IFByb3RlY3Rpb24g TGV2ZWwgMiBzaGFsbCBlbXBsb3kgdGhlIGZvbGxvd2luZyBmZWF0dXJlczo8L2I+CjxCUj48QlI+ CjQuQi4yLmEoNCkgPHU+W0F1ZGl0MV08L3U+IEF1ZGl0aW5nIHByb2NlZHVyZXMsIGluY2x1ZGlu ZzoKPEJSPjxCUj4KNC5CLjIuYSg0KShhKSBQcm92aWRpbmcgdGhlIGNhcGFiaWxpdHkgdG8gZW5z dXJlIHRoYXQgYWxsIGF1ZGl0IHJlY29yZHMgaW5jbHVkZSBlbm91Z2gKaW5mb3JtYXRpb24gdG8g YWxsb3cgdGhlIElTU08gdG8gZGV0ZXJtaW5lIHRoZSBkYXRlIGFuZCB0aW1lIG9mIGFjdGlvbiAo ZS5nLiwKY29tbW9uIG5ldHdvcmsgdGltZSksIHRoZSBzeXN0ZW0gbG9jYWxlIG9mIHRoZSBhY3Rp b24sIHRoZSBzeXN0ZW0gZW50aXR5IHRoYXQKaW5pdGlhdGVkIG9yIGNvbXBsZXRlZCB0aGUgYWN0 aW9uLCB0aGUgcmVzb3VyY2VzIGludm9sdmVkLCBhbmQgdGhlIGFjdGlvbgppbnZvbHZlZC4KPEJS PjxCUj4KNC5CLjIuYSg0KShiKSBQcm90ZWN0aW5nIHRoZSBjb250ZW50cyBvZiBhdWRpdCB0cmFp bHMgYWdhaW5zdCB1bmF1dGhvcml6ZWQgYWNjZXNzLAptb2RpZmljYXRpb24sIG9yIGRlbGV0aW9u Lgo8QlI+PEJSPgo0LkIuMi5hKDQpKGMpIE1haW50YWluaW5nIGNvbGxlY3RlZCBhdWRpdCBkYXRh IGF0IGxlYXN0IDUgeWVhcnMgYW5kIHJldmlld2luZyBhdCBsZWFzdAp3ZWVrbHkuCjxCUj48QlI+ CjQuQi4yLmEoNCkoZCkgVGhlIHN5c3RlbXMgY3JlYXRpbmcgYW5kIG1haW50YWluaW5nIGFuIGF1 ZGl0IHRyYWlsIHRoYXQgaW5jbHVkZXMgc2VsZWN0ZWQ8Yj4gPC9iPnJlY29yZHMKb2Y6IAo8QlI+ PEJSPgo0LkIuMi5hKDQpKGQpKDEpIFN1Y2Nlc3NmdWwgYW5kIHVuc3VjY2Vzc2Z1bCBsb2dvbnMg YW5kIGxvZ29mZnMuCjxCUj48QlI+CjQuQi4yLmEoNCkoZCkoMikgQWNjZXNzZXMgdG8gPGk+c2Vj dXJpdHktcmVsZXZhbnQ8L2k+IG9iamVjdHMgYW5kIGRpcmVjdG9yaWVzLCBpbmNsdWRpbmcgb3Bl bnMsCmNsb3NlcywgbW9kaWZpY2F0aW9ucywgYW5kIGRlbGV0aW9ucy4KPEJSPjxCUj4KNC5CLjIu YSg0KShkKSgzKSBBY3Rpdml0aWVzIGF0IHRoZSBzeXN0ZW0gY29uc29sZSAoZWl0aGVyIHBoeXNp Y2FsIG9yIGxvZ2ljYWwgY29uc29sZXMpLCBhbmQKb3RoZXIgc3lzdGVtLWxldmVsIGFjY2Vzc2Vz IGJ5IHByaXZpbGVnZWQgdXNlcnMuCjxCUj48QlI+CjxIUj4KCgo8Yj5KRENTSVNTUyA3LjUuMy4x IChVKSAoMSBKYW51YXJ5IDIwMDYgUmV2aXNpb24gNCkgQXV0b21hdGVkIEF1ZGl0IFRyYWlsIElu Zm9ybWF0aW9uIFJlcXVpcmVtZW50czwvYj4KPEJSPjxCUj4KSVNzIGFwcHJvdmVkIGZvciBjbGFz c2lmaWVkIHByb2Nlc3Npbmcgc2hvdWxkIGNvbnRhaW4sIGF0IGEgbWluaW11bSwgdGhlIGZvbGxv d2luZyBhdWRpdCB0cmFpbCByZWNvcmRzOgo8QlI+PEJSPgo8VEFCTEUgQk9SREVSPTEgV0lEVEg9 JzEwMCUnIENFTExQQURESU5HPTA+CjxUUj4KPFREIGFsaWduPW1pZGRsZSB2YWxpZ249bWlkZGxl Pk5vLjwvVEQ+CjxURCBhbGlnbj1taWRkbGUgdmFsaWduPW1pZGRsZT48Yj5BdWRpdGFibGUgRXZl bnRzPC9iPjwvVEQ+CjxURCBhbGlnbj1taWRkbGUgdmFsaWduPW1pZGRsZT48Yj5Qcm90ZWN0aW9u IExldmVsPC9iPjwvVEQ+CjxURCBhbGlnbj1taWRkbGUgdmFsaWduPW1pZGRsZT48Yj5TdWNjZXNz PC9iPjwvVEQ+CjxURCBhbGlnbj1taWRkbGUgdmFsaWduPW1pZGRsZT48Yj5GYWlsdXJlPC9iPjwv VEQ+CjxURCBhbGlnbj1taWRkbGUgdmFsaWduPW1pZGRsZT48Yj5SZWQgSGF0IExpbnV4IHN5c2Nh bGwgQXVkaXQgRmxhZyhzKTwvYj48L1REPgo8L1RSPgo8VFI+CjxURCBhbGlnbj1taWRkbGUgdmFs aWduPW1pZGRsZT4xPC9URD4KPFREIGFsaWduPWxlZnQgdmFsaWduPWxlZnQ+TG9nb25zPC9URD4K PFREIGFsaWduPW1pZGRsZSB2YWxpZ249bWlkZGxlPjEtNTwvVEQ+CjxURCBhbGlnbj1taWRkbGUg dmFsaWduPW1pZGRsZT5YPC9URD4KPFREIGFsaWduPW1pZGRsZSB2YWxpZ249bWlkZGxlPlg8L1RE Pgo8VEQgYWxpZ249bWlkZGxlIHZhbGlnbj1taWRkbGU+QXVkaXQgRGVmYXVsdDwvVEQ+CjwvVFI+ CjxUUj4KPFREIGFsaWduPW1pZGRsZSB2YWxpZ249bWlkZGxlPjI8L1REPgo8VEQgYWxpZ249bGVm dCB2YWxpZ249bGVmdD5Mb2dvZmZzPC9URD4KPFREIGFsaWduPW1pZGRsZSB2YWxpZ249bWlkZGxl PjEtNTwvVEQ+CjxURCBhbGlnbj1taWRkbGUgdmFsaWduPW1pZGRsZT4mbmJzcDs8L1REPgo8VEQg YWxpZ249bWlkZGxlIHZhbGlnbj1taWRkbGU+WDwvVEQ+CjxURCBhbGlnbj1taWRkbGUgdmFsaWdu PW1pZGRsZT5BdWRpdCBEZWZhdWx0PC9URD4KPC9UUj4KPFRSPgo8VEQgYWxpZ249bWlkZGxlIHZh bGlnbj1taWRkbGU+MzwvVEQ+CjxURCBhbGlnbj1sZWZ0IHZhbGlnbj1sZWZ0PlNlY3VyaXR5IHJl bGV2YW50IGRpcmVjdG9yaWVzLCBvYmplY3RzLCBhbmQgaW5jaWRlbnRzIChEQUMpPC9URD4KPFRE IGFsaWduPW1pZGRsZSB2YWxpZ249bWlkZGxlPjEtNTwvVEQ+CjxURCBhbGlnbj1taWRkbGUgdmFs aWduPW1pZGRsZT5YPC9URD4KPFREIGFsaWduPW1pZGRsZSB2YWxpZ249bWlkZGxlPlg8L1REPgo8 VEQgYWxpZ249bWlkZGxlIHZhbGlnbj1taWRkbGU+b3BlbiwgY3JlYXQgPC9URD4KPC9UUj4KPFRS Pgo8VEQgYWxpZ249bWlkZGxlIHZhbGlnbj1taWRkbGU+NDwvVEQ+CjxURCBhbGlnbj1sZWZ0IHZh bGlnbj1sZWZ0PlN5c3RlbSBDb25zb2xlIGFjdGl2aXRpZXM8L1REPgo8VEQgYWxpZ249bWlkZGxl IHZhbGlnbj1taWRkbGU+MS01PC9URD4KPFREIGFsaWduPW1pZGRsZSB2YWxpZ249bWlkZGxlPiZu YnNwOzwvVEQ+CjxURCBhbGlnbj1taWRkbGUgdmFsaWduPW1pZGRsZT5YPC9URD4KPFREIGFsaWdu PW1pZGRsZSB2YWxpZ249bWlkZGxlPmNobW9kLCBmY2htb2QsIGNob3duLCBjaG93bjMyLCBmY2hv d24sIGZjaG93bjMyLCBsY2hvd24sIGxjaG93bjMyLCBjcmVhdCwgb3BlbiwgdHJ1bmNhdGUsIHRy dW5jYXRlNjQsIGZ0cnVuY2F0ZSwgZnRydW5jYXRlNjQsIHVsaW5rLCByZW5hbWUsIGxpbmssIHN5 bWxpbmssIG1rbm9kLCBtb3VudCwgdW1vdW50LCB1bW91bnQyLCBjbG9uZSwgZm9yaywgdmZvcmss IHVtYXNrLCBhZGp0aW1leCwgc2V0dGltZW9mZGF5PC9URD4KPC9UUj4KPFRSPgo8VEQgYWxpZ249 bWlkZGxlIHZhbGlnbj1taWRkbGU+NTwvVEQ+CjxURCBhbGlnbj1sZWZ0IHZhbGlnbj1sZWZ0PlVz ZSBvZiBQcml2aWxlZ2VkL1NwZWNpYWwgUmlnaHRzPC9URD4KPFREIGFsaWduPW1pZGRsZSB2YWxp Z249bWlkZGxlPjEtNTwvVEQ+CjxURCBhbGlnbj1taWRkbGUgdmFsaWduPW1pZGRsZT4mbmJzcDs8 L1REPgo8VEQgYWxpZ249bWlkZGxlIHZhbGlnbj1taWRkbGU+WDwvVEQ+CjxURCBhbGlnbj1taWRk bGUgdmFsaWduPW1pZGRsZT5jaG1vZCwgZmNobW9kLCBjaG93biwgY2hvd24zMiwgZmNob3duLCBm Y2hvd24zMiwgbGNob3duLCBsY2hvd24zMiwgY3JlYXQsIG9wZW4sIHRydW5jYXRlLCB0cnVuY2F0 ZTY0LCBmdHJ1bmNhdGUsIGZ0cnVuY2F0ZTY0LCB1bGluaywgcmVuYW1lLCBsaW5rLCBzeW1saW5r LCBta25vZCwgbW91bnQsIHVtb3VudCwgdW1vdW50MjwvVEQ+CjwvVFI+CjxUUj4KPFREIGFsaWdu PW1pZGRsZSB2YWxpZ249bWlkZGxlPjY8L1REPgo8VEQgYWxpZ249bGVmdCB2YWxpZ249bGVmdD5S b290IExldmVsIEFjY2VzczwvVEQ+CjxURCBhbGlnbj1taWRkbGUgdmFsaWduPW1pZGRsZT4xLTU8 L1REPgo8VEQgYWxpZ249bWlkZGxlIHZhbGlnbj1taWRkbGU+WDwvVEQ+CjxURCBhbGlnbj1taWRk bGUgdmFsaWduPW1pZGRsZT5YPC9URD4KPFREIGFsaWduPW1pZGRsZSB2YWxpZ249bWlkZGxlPmNo b3duLCBjaG93bjMyLCBmY2hvd24sIGZjaG93bjMyLCBsY2hvd24sIGxjaG93bjMyLCBhZGp0aW1l eCwgc2V0dGltZW9mZGF5PC9URD4KPC9UUj4KPFRSPgo8VEQgYWxpZ249bWlkZGxlIHZhbGlnbj1t aWRkbGU+NzwvVEQ+CjxURCBhbGlnbj1sZWZ0IHZhbGlnbj1sZWZ0PlVwbG9hZHMgZnJvbSBsb2Nh bCBkZXZpY2VzPC9URD4KPFREIGFsaWduPW1pZGRsZSB2YWxpZ249bWlkZGxlPjEtNTwvVEQ+CjxU RCBhbGlnbj1taWRkbGUgdmFsaWduPW1pZGRsZT5YPC9URD4KPFREIGFsaWduPW1pZGRsZSB2YWxp Z249bWlkZGxlPlg8L1REPgo8VEQgYWxpZ249bWlkZGxlIHZhbGlnbj1taWRkbGU+bW91bnQsIHVt b3VudCwgdW1vdW50MjwvVEQ+CjwvVFI+CjxUUj4KPFREIGFsaWduPW1pZGRsZSB2YWxpZ249bWlk ZGxlPjg8L1REPgo8VEQgYWxpZ249bGVmdCB2YWxpZ249bGVmdD5Xcml0ZXMvRG93bmxvYWRzIHRv IGxvY2FsIGRldmljZXMoQSBkcml2ZXMsIEphenogZHJpdmVzLCBQcmludGVycyk8L1REPgo8VEQg YWxpZ249bWlkZGxlIHZhbGlnbj1taWRkbGU+MS01PC9URD4KPFREIGFsaWduPW1pZGRsZSB2YWxp Z249bWlkZGxlPlg8L1REPgo8VEQgYWxpZ249bWlkZGxlIHZhbGlnbj1taWRkbGU+Jm5ic3A7PC9U RD4KPFREIGFsaWduPW1pZGRsZSB2YWxpZ249bWlkZGxlPm1vdW50LCB1bW91bnQsIHVtb3VudDI8 L1REPgo8L1RSPgo8VFI+CjxURCBhbGlnbj1taWRkbGUgdmFsaWduPW1pZGRsZT45PC9URD4KPFRE IGFsaWduPWxlZnQgdmFsaWduPWxlZnQ+U3lzdGVtIFJlc3RhcnRzL1NodXRkb3duczwvVEQ+CjxU RCBhbGlnbj1taWRkbGUgdmFsaWduPW1pZGRsZT4xLTU8L1REPgo8VEQgYWxpZ249bWlkZGxlIHZh bGlnbj1taWRkbGU+WDwvVEQ+CjxURCBhbGlnbj1taWRkbGUgdmFsaWduPW1pZGRsZT5YPC9URD4K PFREIGFsaWduPW1pZGRsZSB2YWxpZ249bWlkZGxlPnJlYm9vdDwvVEQ+CjwvVFI+CjxUUj4KPFRE IGFsaWduPW1pZGRsZSB2YWxpZ249bWlkZGxlPjEwPC9URD4KPFREIGFsaWduPWxlZnQgdmFsaWdu PWxlZnQ+Q2hhbmdlIG9mIHVzZXJzIGZvcm1hbCBhY2Nlc3MgcGVybWlzc2lvbnM8L1REPgo8VEQg YWxpZ249bWlkZGxlIHZhbGlnbj1taWRkbGU+My01PC9URD4KPFREIGFsaWduPW1pZGRsZSB2YWxp Z249bWlkZGxlPlg8L1REPgo8VEQgYWxpZ249bWlkZGxlIHZhbGlnbj1taWRkbGU+WDwvVEQ+CjxU RCBhbGlnbj1taWRkbGUgdmFsaWduPW1pZGRsZT5OL0E8L1REPgo8L1RSPgo8VFI+CjxURCBhbGln bj1taWRkbGUgdmFsaWduPW1pZGRsZT4xMTwvVEQ+CjxURCBhbGlnbj1sZWZ0IHZhbGlnbj1sZWZ0 PkluZm9ybWF0aW9uIGRvd25ncmFkZXMgYW5kIG92ZXJyaWRlczwvVEQ+CjxURCBhbGlnbj1taWRk bGUgdmFsaWduPW1pZGRsZT40LTU8L1REPgo8VEQgYWxpZ249bWlkZGxlIHZhbGlnbj1taWRkbGU+ WDwvVEQ+CjxURCBhbGlnbj1taWRkbGUgdmFsaWduPW1pZGRsZT5YPC9URD4KPFREIGFsaWduPW1p ZGRsZSB2YWxpZ249bWlkZGxlPk4vQTwvVEQ+CjwvVFI+CjxUUj4KPFREIGFsaWduPW1pZGRsZSB2 YWxpZ249bWlkZGxlPjEyPC9URD4KPFREIGFsaWduPWxlZnQgdmFsaWduPWxlZnQ+QXR0ZW1wdGVk IGFjY2VzcyB0byBvYmplY3RzIG9yIGRhdGEgd2hvc2UgbGFiZWxzIGFyZSBpbmNvbnNpc3RlbnQg d2l0aCB1c2VyIHByaXZpbGVnZXM8L1REPgo8VEQgYWxpZ249bWlkZGxlIHZhbGlnbj1taWRkbGU+ NC01PC9URD4KPFREIGFsaWduPW1pZGRsZSB2YWxpZ249bWlkZGxlPiZuYnNwOzwvVEQ+CjxURCBh bGlnbj1taWRkbGUgdmFsaWduPW1pZGRsZT5YPC9URD4KPFREIGFsaWduPW1pZGRsZSB2YWxpZ249 bWlkZGxlPk4vQTwvVEQ+CjwvVFI+CjxUUj4KPFREIGFsaWduPW1pZGRsZSB2YWxpZ249bWlkZGxl PjEzPC9URD4KPFREIGFsaWduPWxlZnQgdmFsaWduPWxlZnQ+Q2hhbmdlcyB0byBzZWN1cml0eSBs YWJlbHM8L1REPgo8VEQgYWxpZ249bWlkZGxlIHZhbGlnbj1taWRkbGU+NC01PC9URD4KPFREIGFs aWduPW1pZGRsZSB2YWxpZ249bWlkZGxlPlg8L1REPgo8VEQgYWxpZ249bWlkZGxlIHZhbGlnbj1t aWRkbGU+WDwvVEQ+CjxURCBhbGlnbj1taWRkbGUgdmFsaWduPW1pZGRsZT5jaG1vZCwgZmNobW9k LCBjaG93biwgY2hvd24zMiwgZmNob3duLCBmY2hvd24zMiwgbGNob3duLCBsY2hvd24zMiwgdW1h c2s8L1REPgo8L1RSPgo8L1RBQkxFPgoKPGNlbnRlcj4KPGEgaHJlZj0iamF2YXNjcmlwdDp3aW5k b3cuY2xvc2UoKSI+Q2xvc2U8L2E+CjwvY2VudGVyPgoKPC9CT0RZPgo8L0hUTUw+Cg== --00235407f00653dd7a047159511e Content-Type: application/octet-stream; name="AUDIT.RULES" Content-Disposition: attachment; filename="AUDIT.RULES" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fyhg73w60 IyMKIyMgVGhpcyBmaWxlIGNvbnRhaW5zIGEgc2FtcGxlIGF1ZGl0IGNvbmZpZ3VyYXRpb24uICBU aGUgcnVsZXMgY2FuIGJlCiMjIGNvcGllZCBhbmQgcGFzdGVkIGludG8geW91ciBhdWRpdC5ydWxl cyBmaWxlIHVzdWFsbHkgbG9jYXRlZCBpbiB0aGUKIyMgL2V0Yy9hdWRpdC8gZGlyZWN0b3J5LiAK IyMgTm90ZTogQWxsIHNldHRpbmdzIHNob3VsZCBiZSB0ZXN0ZWQgb24gYSBub24tcHJvZHVjdGlv biBzeXN0ZW0gcHJpb3IKIyMgdG8gaW1wbGVtZW50YXRpb24gb24gYW55IHByb2R1Y3Rpb24gc3lz dGVtLgoKIyMgUmVtb3ZlIGFueSBleGlzdGluZyBydWxlcwotRAoKIyMgSW5jcmVhc2UgYnVmZmVy IHNpemUgdG8gaGFuZGxlIHRoZSBpbmNyZWFzZWQgbnVtYmVyIG9mIG1lc3NhZ2VzLgojIyBGZWVs IGZyZWUgdG8gaW5jcmVhc2UgdGhpcyBpZiB0aGUgbWFjaGluZSBwYW5pYydzCi1iIDgxOTIKCiMj IFNldCBmYWlsdXJlIG1vZGUgdG8gcGFuaWMKLWYgMgoKIyMgT3BlcmF0aW9ucyBvbiBmaWxlIHN5 c3RlbSBvYmplY3RzIC0gYnkgZGVmYXVsdCwgb25seSBtb25pdG9yCiMjIGZpbGVzIGFuZCBkaXJl Y3RvcmllcyBjb3ZlcmVkIGJ5IGZpbGVzeXN0ZW0gd2F0Y2hlcy4KCiMjIENoYW5nZXMgaW4gb3du ZXJzaGlwIGFuZCBwZXJtaXNzaW9ucwotYSBlbnRyeSxhbHdheXMgLVMgY2htb2QgLVMgZmNobW9k IC1TIGNob3duIC1TIGZjaG93biAtUyBsY2hvd24KIyMgRW5hYmxlICozMiBydWxlcyBpZiB5b3Ug YXJlIHJ1bm5pbmcgb24gaTM4NiBvciBzMzkwCiMjIERvIG5vdCB1c2UgZm9yIHg4Nl82NCwgaWE2 NCwgcHBjLCBwcGM2NCwgb3IgczM5MHgKIy1hIGVudHJ5LGFsd2F5cyAtUyBmY2hvd24zMgojLWEg ZW50cnksYWx3YXlzIC1TIGNob3duMzIKIy1hIGVudHJ5LGFsd2F5cyAtUyBsY2hvd24zMgoKIyMg RmlsZSBjb250ZW50IG1vZGlmaWNhdGlvbi4gUGVybWlzc2lvbnMgYXJlIGNoZWNrZWQgYXQgb3Bl biB0aW1lLAojIyBtb25pdG9yaW5nIGluZGl2aWR1YWwgcmVhZC93cml0ZSBjYWxscyBpcyBub3Qg dXNlZnVsLgojLWEgZW50cnksYWx3YXlzIC1TIGNyZWF0IC1TIG9wZW4gLVMgdHJ1bmNhdGUgLVMg ZnRydW5jYXRlCiMjIEVuYWJsZSAqNjQgcnVsZXMgaWYgeW91IGFyZSBydW5uaW5nIG9uIGkzODYs IHBwYywgcHBjNjQsIHMzOTAKIyMgRG8gbm90IHVzZSBmb3IgeDg2XzY0LCBpYTY0LCBvciBzMzkw eAojLWEgZW50cnksYWx3YXlzIC1TIHRydW5jYXRlNjQKIy1hIGVudHJ5LGFsd2F5cyAtUyBmdHJ1 bmNhdGU2NAoKIyNVbmF1dGhvcml6ZWQgYWNjZXNzIGF0dGVtcHRzIHRvIGZpbGVzICh1bnN1Y2Nl c3NmdWwpLiBVc2UgYjY0IGZvciA2NCBiaXQgYXJjaGl0ZWN0dXJlCi1hIGV4aXQsYWx3YXlzIGFy Y2g9YjMyIC1TIGNyZWF0IC1TIG9wZW4gLVMgdHJ1bmNhdGUgLVMgZnRydW5jYXRlIC1GIGV4aXQ9 LUVBQ0NFUyAtRiBleGl0PS1FUEVSTSAtRiBhdWlkPj01MDAgLUYgYXVpZCE9NDI5NDk2NzI5NSAt ayBhY2Nlc3MKCiMtYSBleGl0LGFsd2F5cyBhcmNoPWI2NCAtUyBjcmVhdCAtUyBvcGVuIC1TIHRy dW5jYXRlIC1TIGZ0cnVuY2F0ZSAtRiBleGl0PS1FQUNDRVMgLUYgZXhpdD0tRVBFUk0gLUYgYXVp ZD49NTAwIC1GIGF1aWQhPTQyOTQ5NjcyOTUgLWsgYWNjZXNzCgoKIyMgZGlyZWN0b3J5IG9wZXJh dGlvbnMKLWEgZW50cnksYWx3YXlzIC1TIG1rZGlyIC1TIHJtZGlyCgojIyBtb3ZpbmcsIHJlbW92 aW5nLCBhbmQgbGlua2luZwotYSBlbnRyeSxhbHdheXMgLVMgdW5saW5rIC1TIHJlbmFtZSAtUyBs aW5rIC1TIHN5bWxpbmsKCiMjIHNwZWNpYWwgZmlsZXMKLWEgZW50cnksYWx3YXlzIC1TIG1rbm9k CgojIyBPdGhlciBmaWxlIHN5c3RlbSBvcGVyYXRpb25zCi1hIGVudHJ5LGFsd2F5cyAtUyBtb3Vu dAojIyBFbmFibGUgdW1vdW50IHJ1bGUgaWYgeW91IGFyZSBydW5uaW5nIG9uIGkzODYscHBjLHBw YzY0LHMzOTAsczM5MHgsaWE2NAojIyBEbyBub3QgdXNlIGZvciB4ODZfNjQKLWEgZW50cnksYWx3 YXlzIC1TIHVtb3VudAojIyBFbmFibGUgdW1vdW50IHJ1bGUgaWYgeW91IGFyZSBydW5uaW5nIG9u IGkzODYscHBjLHBwYzY0LHMzOTAsczM5MHgsaWE2NAojIyBEbyBub3QgdXNlIGZvciBpYTY0CiMt YSBlbnRyeSxhbHdheXMgLVMgdW1vdW50MgoKIyMgc3VjY2VzcyBhbmQgZmFpbHVyZSBvZiBiaW5k aW5nIHVzZXIgc2VjdXJpdHkgYXR0cmlidXRlcyB0byBhIHN1YmplY3QKIyMKIyMgRW5hYmxlIGlm IHlvdSBhcmUgaW50ZXJlc3RlZCBpbiB0aGVzZSBldmVudHMKIyMKLWEgZW50cnksYWx3YXlzIC1T IGNsb25lCi1hIGVudHJ5LGFsd2F5cyAtUyBmb3JrCi1hIGVudHJ5LGFsd2F5cyAtUyB2Zm9yawoj IyBGb3IgaWE2NCBhcmNoaXRlY3R1cmUsIGRpc2FibGUgZm9yayBhbmQgdmZvcmsgcnVsZXMgYWJv dmUsIGFuZAojIyBlbmFibGUgdGhlIGZvbGxvd2luZzoKIy1hIGVudHJ5LGFsd2F5cyAtUyBjbG9u ZTIKCiMjCiMjIG1vZGlmaWNhdGlvbnMgb2YgdGhlIGRlZmF1bHQgc2V0dGluZyBvZiBwZXJtaXNz aXZlIG9yIHJlc3RyaWN0aXZlCiMjIHJ1bGVzLCBhbGwgbW9kaWZpY2F0aW9ucyBvZiB0aGUgaW5p dGlhbCB2YWx1ZSBvZiBzZWN1cml0eSBhdHRyaWJ1dGVzCiMjCiMjIEVuYWJsZSBpZiB5b3UgYXJl IGludGVyZXN0ZWQgaW4gdGhlc2UgZXZlbnRzCiMjCi1hIGVudHJ5LGFsd2F5cyAtUyB1bWFzawoK IyMKIyMgY2hhbmdlcyB0byB0aGUgdGltZQojIwotYSBlbnRyeSxhbHdheXMgLVMgYWRqdGltZXgg LVMgc2V0dGltZW9mZGF5CgojI1JlY29tbWVuZGVkIEZpbGUgU3lzdGVtIHdhdGNoZXMuIFBsZWFz ZSBhZGQgYW55IG90aGVyIHNlbnNpdGl2ZSBmaWxlcyBhbmQgCiMjZGlyZWN0b3JpZXMgdG8gdGhp cyBsaXN0LgoKIyMKIyMgc3VjY2Vzc2Z1bCBhbmQgdW5zdWNjZXNzZnVsIGF0dGVtcHRzIHRvIHJl YWQgaW5mb3JtYXRpb24gZnJvbSB0aGUKIyMgYXVkaXQgcmVjb3JkczsgYWxsIG1vZGlmaWNhdGlv bnMgdG8gdGhlIGF1ZGl0IHRyYWlsCiMjCi13IC92YXIvbG9nL2F1ZGl0LyAtayBMT0dfYXVkaXQK LXcgL3Zhci9sb2cvYXVkaXQvYXVkaXRfbG9nIC1rIExPR19hdWRpdF9sb2cKLXcgL3Zhci9sb2cv YXVkaXQvYXVkaXRfbG9nLjEgLWsgTE9HX2F1ZGl0X2xvZwotdyAvdmFyL2xvZy9hdWRpdC9hdWRp dF9sb2cuMiAtayBMT0dfYXVkaXRfbG9nCi13IC92YXIvbG9nL2F1ZGl0L2F1ZGl0X2xvZy4zIC1r IExPR19hdWRpdF9sb2cKLXcgL3Zhci9sb2cvYXVkaXQvYXVkaXRfbG9nLjQgLWsgTE9HX2F1ZGl0 X2xvZwoKIyMgCiMjIG1vZGlmaWNhdGlvbnMgdG8gYXVkaXQgY29uZmlndXJhdGlvbiB0aGF0IG9j Y3VyIHdoaWxlIHRoZSBhdWRpdAojIyBjb2xsZWN0aW9uIGZ1bmN0aW9ucyBhcmUgb3BlcmF0aW5n OyBhbGwgbW9kaWNhdGlvbnMgdG8gdGhlIHNldCBvZgojIyBhdWRpdGVkIGV2ZW50cwojIwotdyAv ZXRjL2F1ZGl0L2F1ZGl0ZC5jb25mIC1rIENGR19hdWRpdGQuY29uZgotdyAvZXRjL2F1ZGl0L2F1 ZGl0LnJ1bGVzIC1rIENGR19hdWRpdC5ydWxlcwotdyAvZXRjL2xpYmF1ZGl0LmNvbmYgLXAgd2Eg LWsgQ0ZHX2xpYmF1ZGl0LmNvbmYKCi13IC9ldGMvbnRwLmNvbmYKLXcgL2V0YwotdyAvdmFyL3Nw b29sL2F0Ci13IC9ldGMvYXQuYWxsb3cKLXcgL2V0Yy9hdC5kZW55Ci13IC9ldGMvY3Jvbi5hbGxv dwotdyAvZXRjL2Nyb24uZGVueQotdyAvZXRjL2Nyb24uZC8KLXcgL2V0Yy9jcm9uLmRhaWx5Lwot dyAvZXRjL2Nyb24uaG91cmx5LwotdyAvZXRjL2Nyb24ubW9udGhseS8KLXcgL2V0Yy9jcm9uLndl ZWtseS8KLXcgL2V0Yy9jcm9udGFiCi13IC92YXIvc3Bvb2wvY3Jvbi9yb290Ci13IC9ldGMvYW5h Y3JvbnRhYgotdyAvZXRjL2dyb3VwCi13IC9ldGMvcGFzc3dkCi13IC9ldGMvZ3NoYWRvdwotdyAv ZXRjL3NoYWRvdwotdyAvZXRjL3NoYWRvdy5PTEQKLXcgL2V0Yy9zZWN1cml0eS9vcGFzc3dkCi13 IC9ldGMvc3Vkb2VycwotdyAvZXRjL2xvZ2luLmRlZnMKLXcgL2V0Yy9zZWN1cmV0dHkKLXcgL3Zh ci9sb2cvZmFpbGxvZwotdyAvdmFyL2xvZy9sYXN0bG9nCi13IC9ldGMvc2hlbGxzCi13IC9ldGMv cHJvZmlsZQotdyAvZXRjL2Jhc2hyYwotdyAvZXRjL2NzaC5jc2hyYwotdyAvZXRjL2NzaC5sb2dp bgotdyAvZXRjL2hvc3RzCi13IC9ldGMvc3lzY29uZmlnLwotdyAvZXRjL2RoY3BkLmNvbmYKLXcg L2V0Yy9kaGNsaWVudC1ldGgwLmNvbmYKLXcgL2V0Yy9pbml0dGFiCi13IC9ldGMvcmMuZC9pbml0 LmQvCi13IC9ldGMvcmMuZC9pbml0LmQvYXVkaXRkCi13IC9ldGMvcmMubG9jYWwKLXcgL2V0Yy9y Yy5zeXNpbml0Ci13IC9ldGMveGluZXRkLmNvbmYKLXcgL2V0Yy94aW5ldGQuZC8KLXcgL2V0Yy9s ZC5zby5jb25mCi13IC9ldGMvbGQuc28uY29uZi5kLwotdyAvZXRjL2xvY2FsdGltZQotdyAvZXRj L3N5c2N0bC5jb25mCi13IC9ldGMvbW9kcHJvYmUuY29uZgotdyAvZXRjL3BhbS5kCi13IC9ldGMv cGFtX3NtYi5jb25mCi13IC9ldGMvYWxpYXNlcwotdyAvZXRjL3Bvc3RmaXgvCi13IC9ldGMvbWFp bC9hY2Nlc3MKLXcgL2V0Yy9tYWlsL2FjY2Vzcy5kYgotdyAvZXRjL21haWwvYWxpYXNlcwotdyAv ZXRjL21haWwvZG9tYWludGFibGUKLXcgL2V0Yy9tYWlsL2RvbWFpbnRhYmxlLmRiCi13IC9ldGMv bWFpbC9oZWxwZmlsZQotdyAvZXRjL21haWwvbG9jYWwtaG9zdC1uYW1lcwotdyAvZXRjL21haWwv bWFpbGVydGFibGUKLXcgL2V0Yy9tYWlsL21haWxlcnRhYmxlLmRiCi13IC9ldGMvbWFpbC9NYWtl ZmlsZQotdyAvZXRjL21haWwvc2VuZG1haWwuY2YKLXcgL2V0Yy9tYWlsL3NlbmRtYWlsLm1jCi13 IC9ldGMvbWFpbC9zdWJtaXQuY2YKLXcgL2V0Yy9tYWlsL3N1Ym1pdC5tYwotdyAvZXRjL21haWwv dHJ1c3RlZC11c2VycwotdyAvZXRjL21haWwvdmlydHVzZXJ0YWJsZQotdyAvZXRjL21haWwvdmly dHVzZXJ0YWJsZS5kYgotdyAvZXRjL3NzaC9zc2hkX2NvbmZpZwotdyAvZXRjL3N0dW5uZWwvc3R1 bm5lbC5jb25mCi13IC9ldGMvc3R1bm5lbC9zdHVubmVsLnBlbQotdyAvZXRjL3ZzZnRwZC5mdHB1 c2VycwotdyAvZXRjL3ZzZnRwZC92c2Z0cGQuY29uZgotdyAvZXRjL2h0dHBkL2NvbmYvCi13IC9l dGMvaHR0cGQvY29uZi5kLwotdyAvZXRjL2lzc3VlCi13IC9ldGMvaXNzdWUubmV0Ci13IC9ldGMv c2FtYmEvc21iLmNvbmYKLXcgL2V0Yy9zYW1iYS9zbWJwYXNzd2QKLXcgL2V0Yy9zYW1iYS9zZWNy ZXRzLnRkYgotdyAvZXRjL215LmNvbmYKLXcgL2V0Yy9zeXNsb2cuY29uZgotdyAvZXRjL3NubXAv c25tcGQuY29uZgotdyAvZXRjL3Jlc29sdi5jb25mCi13IC9ldGMvbnNzd2l0Y2guY29uZgotdyAv ZXRjL2hvc3QuY29uZgotdyAvZXRjL3lwLmNvbmYKLXcgL3Zhci95cC9iaW5kaW5nCi13IC9ldGMv bGRhcC5jb25mCi13IC9ldGMva3JiNS5jb25mCi13IC9ldGMva3JiLmNvbmYKLXcgL2V0Yy9rcmIu cmVhbG1zCi13IC9ldGMvaW5pdGxvZy5jb25mCi13IC9ldGMvZGVmYXVsdC8KLXcgL2V0Yy9maXJt d2FyZS9taWNyb2NvZGUuZGF0Ci13IC9ldGMvZnN0YWIKLXcgL2V0Yy9hdXRvLm1hc3RlcgotdyAv ZXRjL2F1dG8ubWlzYwotdyAvZXRjL2hvc3RzLmFsbG93Ci13IC9ldGMvaG9zdHMuZGVueQotdyAv ZXRjL2V4cG9ydHMK --00235407f00653dd7a047159511e Content-Type: text/html; charset=US-ASCII; name="AUDITDESCRIP.HTML" Content-Disposition: attachment; filename="AUDITDESCRIP.HTML" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fyhg9kdb2 PEhUTUw+DQo8VElUTEU+QXVkaXQgUnVsZXMgRGVzY3JpcHRpb25zPC9USVRMRT4NCjxCT0RZIEJH Q09MT1I9d2hpdGU+DQo8YnI+PGNlbnRlcj48aDE+UmVkIEhhdCBTeXNjYWxsIEF1ZGl0aW5nIERl c2NyaXB0aW9uczwvaDE+PC9jZW50ZXI+PGhyPg0KDQo8VEFCTEUgQk9SREVSPTEgV0lEVEg9JzEw MCUnIENFTExQQURESU5HPTA+DQo8VFI+DQo8VEQgYWxpZ249bWlkZGxlIHZhbGlnbj1taWRkbGU+ PGI+U3lzY2FsbCBOYW1lPC9iPjwvVEQ+DQo8VEQgYWxpZ249bWlkZGxlIHZhbGlnbj1taWRkbGU+ PGI+UnVsZTwvYj48L1REPg0KPFREIGFsaWduPW1pZGRsZSB2YWxpZ249bWlkZGxlPjxiPkRlc2Ny aXB0aW9uPC9iPjwvVEQ+DQo8VEQgYWxpZ249bWlkZGxlIHZhbGlnbj1taWRkbGU+PGI+QXVkaXQg SW1wbGljYXRpb248L2I+PC9URD4NCjxURCBhbGlnbj1taWRkbGUgdmFsaWduPW1pZGRsZT48Yj5S ZWNvbW1lbmRhdGlvbiBmb3IgVGFjdGljYWwgU3lzdGVtPC9iPjwvVEQ+DQo8VEQgYWxpZ249bWlk ZGxlIHZhbGlnbj1taWRkbGU+PGI+PC9iPjwvVEQ+DQo8L1RSPg0KPFRSPg0KPFREIGFsaWduPWxl ZnQgdmFsaWduPXRvcD48Yj5jaG1vZCA8YnI+ZmNobW9kPC9iPjwvVEQ+DQo8VEQgYWxpZ249bGVm dCB2YWxpZ249dG9wPi1hIGVudHJ5LGFsd2F5cyAtUyBjaG1vZCAtUyBmY2htb2Q8L1REPg0KPFRE IGFsaWduPWxlZnQgdmFsaWduPXRvcD5jaG1vZCBjaGFuZ2VzIHRoZSBwZXJtaXNzaW9ucyBvZiBl YWNoIGdpdmVuIGZpbGUgYWNjb3JkaW5nIHRvIG1vZGUsIHdoaWNoIGNhbiBiZSBlaXRoZXIgYSBz eW1ib2xpYyByZXByZXNlbnRhdGlvbiBvZiBjaGFuZ2VzIHRvIG1ha2Ugb3IgYW4gb2N0YWwgbnVt YmVyIHJlcHJlc2VudGluZyB0aGUgYml0IHBhdHRlcm4gZm9yIHRoZSBuZXcgcGVybWlzc2lvbjwv VEQ+DQo8VEQgYWxpZ249bGVmdCB2YWxpZ249dG9wPm1vbml0b3JzIGNoYW5nZXMgdG8gZmlsZSBw ZXJtaXNzaW9uczwvVEQ+DQo8VEQgYWxpZ249bWlkZGxlIHZhbGlnbj10b3A+QXVkaXQgYWxsPC9U RD4NCjwvVFI+DQo8VFI+DQo8VEQgYWxpZ249bGVmdCB2YWxpZ249dG9wPjxiPmNob3duIDxicj5j aG93bjMyIDxicj5mY2hvd24gPGJyPmZjaG93bjMyIDxicj5sY2hvd24gPGJyPmxjaG9udzMyPC9i PjwvVEQ+DQo8VEQgYWxpZ249bGVmdCB2YWxpZ249dG9wPi1hIGVudHJ5LGFsd2F5cyAtUyBjaG93 biAtUyBjaG93bjMyIC1TIGZjaG93biAtUyBmY2hvd24zMiAtUyBsY2hvd24gLVMgbGNob3duMzI8 L1REPg0KPFREIGFsaWduPWxlZnQgdmFsaWduPXRvcD5jaG93biBjaGFuZ2VzIHRoZSB1c2VyIGFu ZC9vciBncm91cCBvd25lcnNoaXAgb2YgZWFjaCBnaXZlbiBmaWxlPC9URD4NCjxURCBhbGlnbj1s ZWZ0IHZhbGlnbj10b3A+bW9uaXRvcnMgY2hhbmdlcyB0byBmaWxlIG93bmVyc2hpcDxicj48Yj5O b3RlOjwvYj4gRW5hYmxlICozMiBydWxlcyBvbmx5IGlmIHlvdSBhcmUgcnVubmluZyBvbiBpMzg2 IG9yIHMzOTAuIERvIG5vdCB1c2UgZm9yIHg4Nl82NCwgaWE2NCwgcHBjLCBwcGM2NCwgb3IgczM5 MHguPC9URD4NCjxURCBhbGlnbj1taWRkbGUgdmFsaWduPXRvcD5BdWRpdCBhbGw8L1REPg0KPC9U Uj4NCjxUUj4NCjxURCBhbGlnbj1sZWZ0IHZhbGlnbj10b3A+PGI+Y3JlYXQgPGJyPm9wZW48L2I+ PC9URD4NCjxURCBhbGlnbj1sZWZ0IHZhbGlnbj10b3A+LWEgZW50cnksYWx3YXlzIC1TIGNyZWF0 IC1TIG9wZW48L1REPg0KPFREIGFsaWduPWxlZnQgdmFsaWduPXRvcD5vcGVucyBhbmQgcG9zc2li bGUgY3JlYXRlcyBmaWxlcyBvciBkZXZpY2VzPC9URD4NCjxURCBhbGlnbj1sZWZ0IHZhbGlnbj10 b3A+bW9uaXRvcnMgYWxsIGZpbGUgYWNjZXNzZXMgb2NjdXJyaW5nIG9uIGEgc3lzdGVtPGJyPjxm b250IGNvbG9yPXJlZD48Yj5XQVJOSU5HOjwvYj4gSW1wbGVtZW50aW5nIHRoaXMgcnVsZSB3aWxs IGNhdXNlIGxhcmdlIGFtb3VudHMgb2YgYXVkaXQgZGF0YSB0byBiZSBwcm9kdWNlZC4gRW5zdXJl IHRoZSBhdWRpdCBwYXJ0aXRpb24gYW5kIGxvZyByZXRlbnRpb24gZmFjaWxpdGllcyBhcmUgY2Fw YWJsZSBvZiBoYW5kbGluZyBsYXJnZSBhbW91bnRzIG9mIGF1ZGl0IGRhdGEgYmVmb3JlIGltcGxl bWVudGluZyB0aGlzIHJ1bGUuPC9mb250PjwvVEQ+DQo8VEQgYWxpZ249bWlkZGxlIHZhbGlnbj10 b3A+QXVkaXQgZmFpbHVyZXMgb25seTwvVEQ+DQo8L1RSPg0KPFRSPg0KPFREIGFsaWduPWxlZnQg dmFsaWduPXRvcD48Yj50cnVuY2F0ZSA8YnI+dHJ1bmNhdGU2NCA8YnI+ZnRydW5jYXRlIDxicj5m dHJ1bmNhdGU2NDwvYj48L1REPg0KPFREIGFsaWduPWxlZnQgdmFsaWduPXRvcD4tYSBlbnRyeSxh bHdheXMgLVMgdHJ1bmNhdGUgLVMgdHJ1bmNhdGU2NCAtUyBmdHJ1bmNhdGUgLVMgZnRydW5jYXRl NjQ8L1REPg0KPFREIGFsaWduPWxlZnQgdmFsaWduPXRvcD50cnVuY2F0ZXMgYSBmaWxlIHRvIGEg c3BlY2lmaWVkIGxlbmd0aDwvVEQ+DQo8VEQgYWxpZ249bGVmdCB2YWxpZ249dG9wPm1vbml0b3Jz IGZpbGUgY29udGVudCBtb2RpZmljYXRpb248YnI+PGI+Tm90ZTo8L2I+IEVuYWJsZSAqNjQgcnVs ZXMgaWYgeW91IGFyZSBydW5uaW5nIG9uIGkzODYsIHBwYywgcHBjNjQgb3IgczM5MC4gRG8gbm90 IHVzZSBmb3IgeDg2XzY0LCBpYTY0LCBvciBzMzkweC48L1REPg0KPFREIGFsaWduPW1pZGRsZSB2 YWxpZ249dG9wPkF1ZGl0IGFsbDwvVEQ+DQo8L1RSPg0KPFRSPg0KPFREIGFsaWduPWxlZnQgdmFs aWduPXRvcD48Yj51bmxpbmsgPGJyPmxpbmsgPGJyPnN5bWxpbmsgPGJyPnJlbmFtZTwvYj48L1RE Pg0KPFREIGFsaWduPWxlZnQgdmFsaWduPXRvcD4tYSBlbnRyeSxhbHdheXMgLVMgdW5saW5rIC1T IGxpbmsgLVMgc3ltbGluayAtcyByZW5hbWU8L1REPg0KPFREIGFsaWduPWxlZnQgdmFsaWduPXRv cD51c2VkIHRvIG1vdmUsIGxpbmsgb3IgZGVsZXRlIGZpbGVzPC9URD4NCjxURCBhbGlnbj1sZWZ0 IHZhbGlnbj10b3A+bW9uaXRvcnMgZmlsZSBtb3ZpbmcsIHJlbW92aW5nLCBhbmQgbGlua2luZzwv VEQ+DQo8VEQgYWxpZ249bWlkZGxlIHZhbGlnbj10b3A+QXVkaXQgYWxsPC9URD4NCjwvVFI+DQo8 VFI+DQo8VEQgYWxpZ249bGVmdCB2YWxpZ249dG9wPjxiPm1rbm9kPC9iPjwvVEQ+DQo8VEQgYWxp Z249bGVmdCB2YWxpZ249dG9wPi1hIGVudHJ5LGFsd2F5cyAtUyBta25vZDwvVEQ+DQo8VEQgYWxp Z249bGVmdCB2YWxpZ249dG9wPmNyZWF0ZXMgYmxvY2sgb3IgY2hhcmFjdGVyIHNwZWNpYWwgZmls ZXM8L1REPg0KPFREIGFsaWduPWxlZnQgdmFsaWduPXRvcD5tb25pdG9ycyB0aGUgY3JlYXRpb24g b2Ygc3BlY2lhbCBmaWxlczwvVEQ+DQo8VEQgYWxpZ249bWlkZGxlIHZhbGlnbj10b3A+QXVkaXQg YWxsPC9URD4NCjwvVFI+DQo8VFI+DQo8VEQgYWxpZ249bGVmdCB2YWxpZ249dG9wPjxiPm1vdW50 IDxicj51bW91bnQgPGJyPnVtb3VudDI8L2I+PC9URD4NCjxURCBhbGlnbj1sZWZ0IHZhbGlnbj10 b3A+LWEgZW50cnksYWx3YXlzIC1TIG1vdW50IC1TIHVtb3VudCAtUyB1bW91bnQyPC9URD4NCjxU RCBhbGlnbj1sZWZ0IHZhbGlnbj10b3A+TW91bnRzIG9yIHVubW91bnRzIGEgZmlsZSBzeXN0ZW08 L1REPg0KPFREIGFsaWduPWxlZnQgdmFsaWduPXRvcD5Nb25pdG9ycyB0aGUgbW91bnRpbmcgb3Ig dW5tb3VudGluZyBvZiBmaWxlIHN5c3RlbXM8YnI+PGI+Tm90ZTo8L2I+IEZvciB4ODZfNjQgYXJj aGl0ZWN0dXJlLCBkaXNhYmxlIHVtb3VudCBydWxlLiBGb3IgaWE2NCBhcmNoaXRlY3R1cmUsIGRp c2FibGUgdW1vdW50MiBydWxlLjwvVEQ+DQo8VEQgYWxpZ249bWlkZGxlIHZhbGlnbj10b3A+QXVk aXQgYWxsPC9URD4NCjwvVFI+DQo8VFI+DQo8VEQgYWxpZ249bGVmdCB2YWxpZ249dG9wPjxiPmNs b25lIDxicj5jbG9uZTIgPGJyPmZvcmsgPGJyPnZmb3JrPC9iPjwvVEQ+DQo8VEQgYWxpZ249bGVm dCB2YWxpZ249dG9wPi1hIGVudHJ5LGFsd2F5cyAtUyBjbG9uZSAtUyBjbG9uZTIgLVMgZm9yayAt UyB2Zm9yazwvVEQ+DQo8VEQgYWxpZ249bGVmdCB2YWxpZ249dG9wPkNyZWF0ZXMgY2hpbGQgcHJv Y2Vzc2VzPC9URD4NCjxURCBhbGlnbj1sZWZ0IHZhbGlnbj10b3A+bW9uaXRvcnMgdGhlIGNyZWF0 aW9uIG9mIGNoaWxkIHByb2Nlc3Nlczxicj48Yj5Ob3RlOjwvYj4gRm9yIGlhNjQgYXJjaGl0ZWN0 dXJlLCBkaXNhYmxlIGZvcmsgYW5kIHZmb3JrIGFuZCBlbmFibGUgY2xvbmUyLiA8YnI+PGZvbnQg Y29sb3I9cmVkPjxiPldBUk5JTkc6PC9iPiBJbXBsZW1lbnRpbmcgdGhpcyBydWxlIHdpbGwgY2F1 c2UgbGFyZ2UgYW1vdW50cyBvZiBhdWRpdCBkYXRhIHRvIGJlIHByb2R1Y2VkLiBFbnN1cmUgdGhl IGF1ZGl0IHBhcnRpdGlvbiBhbmQgbG9nIHJldGVudGlvbiBmYWNpbGl0aWVzIGFyZSBjYXBhYmxl IG9mIGhhbmRsaW5nIGxhcmdlIGFtb3VudHMgb2YgYXVkaXQgZGF0YSBiZWZvcmUgaW1wbGVtZW50 aW5nIHRoaXMgcnVsZS48L2ZvbnQ+PC9URD4NCjxURCBhbGlnbj1taWRkbGUgdmFsaWduPXRvcD5v ZmY8L1REPg0KPC9UUj4NCjxUUj4NCjxURCBhbGlnbj1sZWZ0IHZhbGlnbj10b3A+PGI+dW1hc2s8 L2I+PC9URD4NCjxURCBhbGlnbj1sZWZ0IHZhbGlnbj10b3A+LWEgZW50cnksYWx3YXlzIC1TIHVt YXNrPC9URD4NCjxURCBhbGlnbj1sZWZ0IHZhbGlnbj10b3A+dXNlciBmaWxlIGNyZWF0aW9uIG1h c2s8L1REPg0KPFREIGFsaWduPWxlZnQgdmFsaWduPXRvcD5tb25pdG9ycyBjaGFuZ2VzIHRvIHVt YXNrIHNldHRpbmdzPC9URD4NCjxURCBhbGlnbj1taWRkbGUgdmFsaWduPXRvcD5BdWRpdCBhbGw8 L1REPg0KPC9UUj4NCjxUUj4NCjxURCBhbGlnbj1sZWZ0IHZhbGlnbj10b3A+PGI+YWRqdGltZXgg PGJyPnNldHRpbWVvZmRheTwvYj48L1REPg0KPFREIGFsaWduPWxlZnQgdmFsaWduPXRvcD4tYSBl bnRyeSxhbHdheXMgLVMgYWRqdGltZXggLVMgc2V0dGltZW9mZGF5PC9URD4NCjxURCBhbGlnbj1s ZWZ0IHZhbGlnbj10b3A+Y2hhbmdlcyB0aGUgc3lzdGVtIHRpbWU8L1REPg0KPFREIGFsaWduPWxl ZnQgdmFsaWduPXRvcD5tb25pdG9ycyBjaGFuZ2VzIHRvIHRoZSBzeXN0ZW0gdGltZTwvVEQ+DQo8 VEQgYWxpZ249bWlkZGxlIHZhbGlnbj10b3A+QXVkaXQgYWxsPC9URD4NCjwvVFI+DQo8VFI+DQo8 VEQgYWxpZ249bGVmdCB2YWxpZ249dG9wPjxiPnJlYm9vdDwvYj48L1REPg0KPFREIGFsaWduPWxl ZnQgdmFsaWduPXRvcD4tYSBlbnRyeSwgYWx3YXlzIC1TIHJlYm9vdDwvVEQ+DQo8VEQgYWxpZ249 bGVmdCB2YWxpZ249dG9wPnJlYm9vdCBvciBlbmFibGUvZGlzYWJsZSBDdHJsLUFsdC1EZWw8L1RE Pg0KPFREIGFsaWduPWxlZnQgdmFsaWduPXRvcD5tb25pdG9ycyBzeXN0ZW0gcmVib290czwvVEQ+ DQo8VEQgYWxpZ249bWlkZGxlIHZhbGlnbj10b3A+QXVkaXQgYWxsPC9URD4NCjwvVFI+DQo8L1RB QkxFPg0KDQo8Y2VudGVyPg0KPGEgaHJlZj0iamF2YXNjcmlwdDp3aW5kb3cuY2xvc2UoKSI+Q2xv c2U8L2E+DQo8L2NlbnRlcj4NCg0KPC9CT0RZPg0KPC9IVE1MPg== --00235407f00653dd7a047159511e Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --00235407f00653dd7a047159511e-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Flatley Subject: Re: buffer space Date: Mon, 17 Aug 2009 13:06:01 -0400 Message-ID: References: <200908131428.52924.sgrubb@redhat.com> <200908171108.00417.sgrubb@redhat.com> <1250527972.3048.693.camel@homeserver> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1881743823==" Return-path: In-Reply-To: <1250527972.3048.693.camel@homeserver> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: LC Bruzenak Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com --===============1881743823== Content-type: multipart/alternative; Boundary="0__=0ABBFC86DFCE15EA8f9e8a93df938690918c0ABBFC86DFCE15EA" Content-Disposition: inline --0__=0ABBFC86DFCE15EA8f9e8a93df938690918c0ABBFC86DFCE15EA Content-type: text/plain; charset=US-ASCII Lenny: I was going to move the rotated logs into /home/logs and use "ausearch -i -f /home/logs". David Flatley CISSP --0__=0ABBFC86DFCE15EA8f9e8a93df938690918c0ABBFC86DFCE15EA Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Lenny:

I was going to move the rotated logs into /home/logs and use "ausearch -i -f /home/logs".


David Flatley CISSP
--0__=0ABBFC86DFCE15EA8f9e8a93df938690918c0ABBFC86DFCE15EA-- --===============1881743823== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============1881743823==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: LC Bruzenak Subject: Re: buffer space Date: Mon, 17 Aug 2009 12:15:56 -0500 Message-ID: <1250529356.3048.700.camel@homeserver> References: <200908131428.52924.sgrubb@redhat.com> <200908171108.00417.sgrubb@redhat.com> <1250527972.3048.693.camel@homeserver> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: David Flatley Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Mon, 2009-08-17 at 13:06 -0400, David Flatley wrote: > Lenny: > > I was going to move the rotated logs into /home/logs and use "ausearch > -i -f /home/logs". > > > David Flatley CISSP > > David, It won't work like that; exactly the issue I described: [root@slim root]# mkdir logs-test [root@slim root]# cd !$ cd logs-test [root@slim logs-test]# auditctl -m "TEST message" [root@slim logs-test]# service auditd rotate Rotating logs: [ OK ] [root@slim logs-test]# cp /var/log/audit/audit.log.1 . [root@slim logs-test]# ausearch -i -f `pwd` -m USER [root@slim logs-test]# grep TEST audit.log.1 node=slim type=USER msg=audit(1250529052.265:305135): user pid=8191 uid=0 auid=500 ses=4172 subj=user_u:user_r:user_t:s0 msg='TEST message: exe="/sbin/auditctl" (hostname=?, addr=?, terminal=pts/18 res=success)' LCB. -- LC (Lenny) Bruzenak lenny@magitekltd.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: LC Bruzenak Subject: Re: buffer space Date: Mon, 17 Aug 2009 12:24:31 -0500 Message-ID: <1250529871.3048.706.camel@homeserver> References: <200908131428.52924.sgrubb@redhat.com> <200908171108.00417.sgrubb@redhat.com> <1250527972.3048.693.camel@homeserver> <1250529356.3048.700.camel@homeserver> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (mx1.redhat.com [172.16.48.31]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n7HHOlQM029419 for ; Mon, 17 Aug 2009 13:24:47 -0400 Received: from mail.magitekltd.com (rrcs-24-242-137-197.sw.biz.rr.com [24.242.137.197]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n7HHOWRA031789 for ; Mon, 17 Aug 2009 13:24:32 -0400 In-Reply-To: <1250529356.3048.700.camel@homeserver> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: David Flatley Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Mon, 2009-08-17 at 12:15 -0500, LC Bruzenak wrote: > On Mon, 2009-08-17 at 13:06 -0400, David Flatley wrote: > > Lenny: > > > > I was going to move the rotated logs into /home/logs and use "ausearch > > -i -f /home/logs". > > > > > > David Flatley CISSP > > > > > > David, > > It won't work like that; exactly the issue I described: > > [root@slim root]# mkdir logs-test > [root@slim root]# cd !$ > cd logs-test > [root@slim logs-test]# auditctl -m "TEST message" > [root@slim logs-test]# service auditd rotate > Rotating logs: [ OK ] > [root@slim logs-test]# cp /var/log/audit/audit.log.1 . > [root@slim logs-test]# ausearch -i -f `pwd` -m USER > > [root@slim logs-test]# grep TEST audit.log.1 > node=slim type=USER msg=audit(1250529052.265:305135): user pid=8191 > uid=0 auid=500 ses=4172 subj=user_u:user_r:user_t:s0 msg='TEST message: > exe="/sbin/auditctl" (hostname=?, addr=?, terminal=pts/18 res=success)' > > > LCB. > David, I should have been more diligent. The input switch was supposed to be "-if" IIUC. The "-f" switch is looking for a filename inside the record. [root@slim logs-test]# ausearch -i -if `pwd` -m USER [root@slim logs-test]# ausearch -i -if `pwd`/audit.log.1 -m USER ... ---- node=slim type=USER msg=audit(08/17/2009 12:10:52.265:305135) : user pid=8191 uid=root auid=lcb ses=4172 subj=user_u:user_r:user_t:s0 msg='TEST message: exe=/sbin/auditctl (hostname=?, addr=?, terminal=pts/18 res=success)' ... This is what you want to do right - search inside a directory other than /var/log/audit with multiple audit logs inside the directory? LCB. -- LC (Lenny) Bruzenak lenny@magitekltd.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Flatley Subject: Re: buffer space Date: Mon, 17 Aug 2009 13:32:33 -0400 Message-ID: References: <200908131428.52924.sgrubb@redhat.com> <200908171108.00417.sgrubb@redhat.com> <1250527972.3048.693.camel@homeserver> <1250529356.3048.700.camel@homeserver> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1330088795==" Return-path: In-Reply-To: <1250529356.3048.700.camel@homeserver> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: LC Bruzenak Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com --===============1330088795== Content-type: multipart/related; Boundary="0__=0ABBFC86DFCCDE868f9e8a93df938690918c0ABBFC86DFCCDE86" --0__=0ABBFC86DFCCDE868f9e8a93df938690918c0ABBFC86DFCCDE86 Content-type: multipart/alternative; Boundary="1__=0ABBFC86DFCCDE868f9e8a93df938690918c0ABBFC86DFCCDE86" --1__=0ABBFC86DFCCDE868f9e8a93df938690918c0ABBFC86DFCCDE86 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable >> Lenny: >> >> I was going to move the rotated logs into /home/logs and use "ausear= ch >> -i -f /home/logs". >> >> >> David Flatley CISSP >> >> >David, > >It won't work like that; exactly the issue I described: > >[root@slim root]# mkdir logs-test >[root@slim root]# cd !$ >cd logs-test >[root@slim logs-test]# auditctl -m "TEST message" >[root@slim logs-test]# service auditd rotate >Rotating logs: [ OK ] >[root@slim logs-test]# cp /var/log/audit/audit.log.1 . >[root@slim logs-test]# ausearch -i -f `pwd` -m USER > >[root@slim logs-test]# grep TEST audit.log.1 >node=3Dslim type=3DUSER msg=3Daudit(1250529052.265:305135): user pid=3D= 8191 >uid=3D0 auid=3D500 ses=3D4172 subj=3Duser_u:user_r:user_t:s0 msg=3D'TE= ST message: >exe=3D"/sbin/auditctl" (hostname=3D?, addr=3D?, terminal=3Dpts/18 res=3D= success)' > > >LCB. UGH this is a wrench in the works... I was hoping to grab all the rotated logs, process them while still allowing audit to run with no interruptions. Problem I run into is I run ausearch -i > /tmp/file and then do ausearch -i /nfs/file with auditd stopped, then compare files and if= they are the same in size then delete the /tmp/file. I do this to make sure I get the log in= the nfs archive directory and the /tmp is a backup if there is a problem. If audit is running the= re is no way the files will be equal in size while processing the /var/log/audit data in two differ= ent intervals. Thanks for feedback on this Lenny. David Flatley CISSP = = From: LC Bruzenak = = = = To: David Flatley/Burlington/IBM@IBMUS = = = = Cc: linux-audit@redhat.com, Steve Grubb = = = = Date: 08/17/2009 01:16 PM = = = = Subject: Re: buffer space = = = = On Mon, 2009-08-17 at 13:06 -0400, David Flatley wrote: > Lenny: > > I was going to move the rotated logs into /home/logs and use "ausearc= h > -i -f /home/logs". > > > David Flatley CISSP > > David, It won't work like that; exactly the issue I described: [root@slim root]# mkdir logs-test [root@slim root]# cd !$ cd logs-test [root@slim logs-test]# auditctl -m "TEST message" [root@slim logs-test]# service auditd rotate Rotating logs: [ OK ] [root@slim logs-test]# cp /var/log/audit/audit.log.1 . [root@slim logs-test]# ausearch -i -f `pwd` -m USER [root@slim logs-test]# grep TEST audit.log.1 node=3Dslim type=3DUSER msg=3Daudit(1250529052.265:305135): user pid=3D= 8191 uid=3D0 auid=3D500 ses=3D4172 subj=3Duser_u:user_r:user_t:s0 msg=3D'TES= T message: exe=3D"/sbin/auditctl" (hostname=3D?, addr=3D?, terminal=3Dpts/18 res=3D= success)' LCB. -- LC (Lenny) Bruzenak lenny@magitekltd.com = --1__=0ABBFC86DFCCDE868f9e8a93df938690918c0ABBFC86DFCCDE86 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

>> Lenny:
>>
>> I was going to move the rotated logs into /home/logs and use &= quot;ausearch
>> -i -f /home/logs".
>>
>>
>> David Flatley CISSP
>>
>>

>David,
>
>It won't work like that; exactly the issue I described:
>
>[root@slim root]# mkdir logs-test
>[root@slim root]# cd !$
>cd logs-test
>[root@slim logs-test]# auditctl -m "TEST message"
>[root@slim logs-test]# service auditd rotate
>Rotating logs:               &nb= sp;                   &nbs= p;         [  OK  ]
>[root@slim logs-test]# cp /var/log/audit/audit.log.1 .
>[root@slim logs-test]# ausearch -i -f `pwd` -m USER
><no matches>
>[root@slim logs-test]# grep TEST audit.log.1
>node=3Dslim type=3DUSER msg=3Daudit(1250529052.265:305135): user pi= d=3D8191
>uid=3D0 auid=3D500 ses=3D4172 subj=3Duser_u:user_r:user_t:s0 msg=3D= 'TEST message:
>exe=3D"/sbin/auditctl" (hostname=3D?, addr=3D?, terminal=3D= pts/18 res=3Dsuccess)'
>
>
>LCB.

  UGH this is a wrench in the works...
  I was hoping to grab all the rotated logs, process them whil= e still allowing audit
to run with no interruptions. Problem I run into is I run ausearch = -i > /tmp/file and then
do ausearch -i /nfs/file with auditd stopped, then compare files an= d if they are the same in
size then delete the /tmp/file. I do this to make sure I get the lo= g in the nfs archive directory
and the /tmp is a backup if there is a problem. If audit is running= there is no way the files will
be equal in size while processing the /var/log/audit data in two di= fferent intervals.

  Thanks for feedback on this Lenny.  


David Flatley CISSP



3D"InactiveLC Bruzenak ---08= /17/2009 01:16:30 PM---On Mon, 2009-08-17 at 13:06 -0400, David Flatley= wrote: > Lenny:

=
3D=
From:
= 3D""
LC Bruzenak <lenny@magitekltd.com>
3D=
To:

David Flatley/Burlington/IBM@IBMUS
3D=
Cc:
3D""
linux-audit@redhat.com, Steve Grubb <sgrubb@redhat.= com>
3D=
Date:
= 3D""
08/17/2009 01:16 PM
3D=
Subject:
3D""
Re: buffer space






On Mon, 2009-08-17 at 13:06 -0400, David Flatley wrote:
> Lenny:
>
> I was going to move the rotated logs into /home/logs and use "= ;ausearch
> -i -f /home/logs".
>
>
> David Flatley CISSP
>
>

David,

It won't work like that; exactly the issue I described:

[root@slim root]# mkdir logs-test
[root@slim root]# cd !$
cd logs-test
[root@slim logs-test]# auditctl -m "TEST message"
[root@slim logs-test]# service auditd rotate
Rotating logs:                 =                     &= nbsp;       [  OK  ]
[root@slim logs-test]# cp /var/log/audit/audit.log.1 .
[root@slim logs-test]# ausearch -i -f `pwd` -m USER
<no matches>
[root@slim logs-test]# grep TEST audit.log.1
node=3Dslim type=3DUSER msg=3Daudit(1250529052.265:305135): user pid=3D= 8191
uid=3D0 auid=3D500 ses=3D4172 subj=3Duser_u:user_r:user_t:s0 msg=3D'TES= T message:
exe=3D"/sbin/auditctl" (hostname=3D?, addr=3D?, terminal=3Dpt= s/18 res=3Dsuccess)'


LCB.

--
LC (Lenny) Bruzenak
lenny@magitekltd.com



= --1__=0ABBFC86DFCCDE868f9e8a93df938690918c0ABBFC86DFCCDE86-- --0__=0ABBFC86DFCCDE868f9e8a93df938690918c0ABBFC86DFCCDE86 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABBFC86DFCCDE868f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBFC86DFCCDE868f9e8a93df938690918c0ABBFC86DFCCDE86 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <2__=0ABBFC86DFCCDE868f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBFC86DFCCDE868f9e8a93df938690918c0ABBFC86DFCCDE86-- --===============1330088795== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============1330088795==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: LC Bruzenak Subject: Re: buffer space Date: Mon, 17 Aug 2009 12:46:03 -0500 Message-ID: <1250531163.3048.720.camel@homeserver> References: <200908131428.52924.sgrubb@redhat.com> <200908171108.00417.sgrubb@redhat.com> <1250527972.3048.693.camel@homeserver> <1250529356.3048.700.camel@homeserver> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: David Flatley Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Mon, 2009-08-17 at 13:32 -0400, David Flatley wrote: > >> Lenny: > >> > >> I was going to move the rotated logs into /home/logs and use > "ausearch > >> -i -f /home/logs". > >> > >> > >> David Flatley CISSP > >> > >> > > >David, > > > >It won't work like that; exactly the issue I described: > > > >[root@slim root]# mkdir logs-test > >[root@slim root]# cd !$ > >cd logs-test > >[root@slim logs-test]# auditctl -m "TEST message" > >[root@slim logs-test]# service auditd rotate > >Rotating logs: [ OK ] > >[root@slim logs-test]# cp /var/log/audit/audit.log.1 . > >[root@slim logs-test]# ausearch -i -f `pwd` -m USER > > > >[root@slim logs-test]# grep TEST audit.log.1 > >node=slim type=USER msg=audit(1250529052.265:305135): user pid=8191 > >uid=0 auid=500 ses=4172 subj=user_u:user_r:user_t:s0 msg='TEST > message: > >exe="/sbin/auditctl" (hostname=?, addr=?, terminal=pts/18 > res=success)' > > > > > >LCB. > > UGH this is a wrench in the works... > I was hoping to grab all the rotated logs, process them while still > allowing audit > to run with no interruptions. Problem I run into is I run ausearch -i > > /tmp/file and then > do ausearch -i /nfs/file with auditd stopped, then compare files and > if they are the same in > size then delete the /tmp/file. I do this to make sure I get the log > in the nfs archive directory > and the /tmp is a backup if there is a problem. If audit is running > there is no way the files will > be equal in size while processing the /var/log/audit data in two > different intervals. It's a problem for me too. I was thinking about just patching the ausearch code to behave as desired...but hoping Steve beat me to it so there was a greatly reduced chance of bad code... :) As for the archive issue, what I am planning is to make a snapshot of my current audit log directory (technically the partition on which this lives; that's another SECSCN issue), then rsync the snapshot over to a backup server (via crossover network connection) and finally release the snap mount. Then I do not have to compare file sizes ... and really the size is only one indicator of correctness. You'd probably need a checksum activity. LCB. -- LC (Lenny) Bruzenak lenny@magitekltd.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: buffer space Date: Mon, 17 Aug 2009 14:01:05 -0400 Message-ID: <200908171401.11835.sgrubb@redhat.com> References: <1250531163.3048.720.camel@homeserver> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1250531163.3048.720.camel@homeserver> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: LC Bruzenak Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Monday 17 August 2009 01:46:03 pm LC Bruzenak wrote: > > UGH this is a wrench in the works... > > I was hoping to grab all the rotated logs, process them while still > > allowing audit > > to run with no interruptions. Problem I run into is I run ausearch -i > > > > > /tmp/file and then > > > > do ausearch -i /nfs/file with auditd stopped, then compare files and > > if they are the same in > > size then delete the /tmp/file. I do this to make sure I get the log > > in the nfs archive directory > > and the /tmp is a backup if there is a problem. If audit is running > > there is no way the files will > > be equal in size while processing the /var/log/audit data in two > > different intervals. > > It's a problem for me too. > I was thinking about just patching the ausearch code to behave as > desired...but hoping Steve beat me to it so there was a greatly reduced > chance of bad code... #cat `ls /var/log/audit/a* | sort -r` | ausearch -i #cat `ls /var/log/audit/a* | sort -r` | aureport cat can open more than one file at a time, -Steve From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Norman Mark St. Laurent" Subject: Re: buffer space Date: Mon, 17 Aug 2009 14:13:45 -0400 Message-ID: <4A899DD9.40900@conceras.com> References: <1250531163.3048.720.camel@homeserver> <200908171401.11835.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (mx1.redhat.com [172.16.48.31]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n7HIE6R7008080 for ; Mon, 17 Aug 2009 14:14:06 -0400 Received: from p3plsmtpa01-04.prod.phx3.secureserver.net (p3plsmtpa01-04.prod.phx3.secureserver.net [72.167.82.84]) by mx1.redhat.com (8.13.8/8.13.8) with SMTP id n7HIDlvq003005 for ; Mon, 17 Aug 2009 14:13:49 -0400 In-Reply-To: <200908171401.11835.sgrubb@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com cat --> zcat for the gzip files... THANKS Steve... Very Nice.... Norman Mark St. Laurent Conceras | Chief Technology Officer and ISSE Phone: 703-965-4892 Email: mstlaurent@conceras.com Web: http://www.conceras.com Connect. Collaborate. Conceras. Steve Grubb wrote: > On Monday 17 August 2009 01:46:03 pm LC Bruzenak wrote: > >>> UGH this is a wrench in the works... >>> I was hoping to grab all the rotated logs, process them while still >>> allowing audit >>> to run with no interruptions. Problem I run into is I run ausearch -i >>> >>> >>>> /tmp/file and then >>>> >>> do ausearch -i /nfs/file with auditd stopped, then compare files and >>> if they are the same in >>> size then delete the /tmp/file. I do this to make sure I get the log >>> in the nfs archive directory >>> and the /tmp is a backup if there is a problem. If audit is running >>> there is no way the files will >>> be equal in size while processing the /var/log/audit data in two >>> different intervals. >>> >> It's a problem for me too. >> I was thinking about just patching the ausearch code to behave as >> desired...but hoping Steve beat me to it so there was a greatly reduced >> chance of bad code... >> > > #cat `ls /var/log/audit/a* | sort -r` | ausearch -i > #cat `ls /var/log/audit/a* | sort -r` | aureport > > cat can open more than one file at a time, > > -Steve > > -- > Linux-audit mailing list > Linux-audit@redhat.com > https://www.redhat.com/mailman/listinfo/linux-audit > > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: LC Bruzenak Subject: Re: buffer space Date: Mon, 17 Aug 2009 13:14:54 -0500 Message-ID: <1250532894.3048.729.camel@homeserver> References: <1250531163.3048.720.camel@homeserver> <200908171401.11835.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200908171401.11835.sgrubb@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Mon, 2009-08-17 at 14:01 -0400, Steve Grubb wrote: > > > It's a problem for me too. > > I was thinking about just patching the ausearch code to behave as > > desired...but hoping Steve beat me to it so there was a greatly > reduced > > chance of bad code... > > #cat `ls /var/log/audit/a* | sort -r` | ausearch -i > #cat `ls /var/log/audit/a* | sort -r` | aureport > > cat can open more than one file at a time, > > -Steve Told you so! :) LCB. -- LC (Lenny) Bruzenak lenny@magitekltd.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Norman Mark St. Laurent" Subject: Re: buffer space Date: Mon, 17 Aug 2009 14:46:30 -0400 Message-ID: <4A89A586.9020008@conceras.com> References: <1250531163.3048.720.camel@homeserver> <200908171401.11835.sgrubb@redhat.com> <1250532894.3048.729.camel@homeserver> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mx3.redhat.com (mx3.redhat.com [172.16.48.32]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n7HIlKCj004522 for ; Mon, 17 Aug 2009 14:47:20 -0400 Received: from smtpauth16.prod.mesa1.secureserver.net (smtpauth16.prod.mesa1.secureserver.net [64.202.165.22]) by mx3.redhat.com (8.13.8/8.13.8) with SMTP id n7HIl3RW003383 for ; Mon, 17 Aug 2009 14:47:03 -0400 In-Reply-To: <1250532894.3048.729.camel@homeserver> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: LC Bruzenak Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com Depending if you are using logrotate.d/audit and how it numbers the files as it rotates... audit.log.1.gz audit.log.2.gz ... audit.log.89.gz audit.log.90.gz The sort below will but the list in exact order.... zcat `ls /var/log/audit/*.gz | sort -t. --key=3,2n` | ausearch -i Thank u Steve... Norman Mark St. Laurent Conceras | Chief Technology Officer and ISSE Web: http://www.conceras.com Connect. Collaborate. Conceras. LC Bruzenak wrote: > On Mon, 2009-08-17 at 14:01 -0400, Steve Grubb wrote: > >>> It's a problem for me too. >>> I was thinking about just patching the ausearch code to behave as >>> desired...but hoping Steve beat me to it so there was a greatly >>> >> reduced >> >>> chance of bad code... >>> >> #cat `ls /var/log/audit/a* | sort -r` | ausearch -i >> #cat `ls /var/log/audit/a* | sort -r` | aureport >> >> cat can open more than one file at a time, >> >> -Steve >> > > Told you so! > :) > > LCB. > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: buffer space Date: Mon, 17 Aug 2009 15:37:37 -0400 Message-ID: <200908171537.37593.sgrubb@redhat.com> References: <1250532894.3048.729.camel@homeserver> <4A89A586.9020008@conceras.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4A89A586.9020008@conceras.com> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: "Norman Mark St. Laurent" Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Monday 17 August 2009 02:46:30 pm Norman Mark St. Laurent wrote: > Depending if you are using logrotate.d/audit and how it numbers the > files as it rotates... > > audit.log.1.gz > audit.log.2.gz > ... > audit.log.89.gz > audit.log.90.gz > > The sort below will but the list in exact order.... > > zcat `ls /var/log/audit/*.gz | sort -t. --key=3,2n` | ausearch -i For this to work right, it has to be in descending order. So, add a -r to the sort command. -Steve From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Norman Mark St. Laurent" Subject: Re: buffer space Date: Mon, 17 Aug 2009 15:46:15 -0400 Message-ID: <4A89B387.4070107@conceras.com> References: <1250532894.3048.729.camel@homeserver> <4A89A586.9020008@conceras.com> <200908171537.37593.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (mx1.redhat.com [172.16.48.31]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n7HJkYJQ017578 for ; Mon, 17 Aug 2009 15:46:34 -0400 Received: from smtpauth23.prod.mesa1.secureserver.net (smtpauth23.prod.mesa1.secureserver.net [64.202.165.47]) by mx1.redhat.com (8.13.8/8.13.8) with SMTP id n7HJkHx2031892 for ; Mon, 17 Aug 2009 15:46:17 -0400 In-Reply-To: <200908171537.37593.sgrubb@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com Ok, For some reason sort -r will not work with sort -t. --key=3,2n options I tried: sort -r -t. --key=3,2n sort -t. -r --key=3,2n sort -t. --key=3,2n -r But.... zcat `ls /var/log/audit/*.gz | sort -t. --key=3,2n` | tac | ausearch -i works like a champ. Gotta luv linux.. Thnks.. Norman Mark St. Laurent Conceras | Chief Technology Officer and ISSE Phone: 703-965-4892 Email: mstlaurent@conceras.com Web: http://www.conceras.com Connect. Collaborate. Conceras. Steve Grubb wrote: > On Monday 17 August 2009 02:46:30 pm Norman Mark St. Laurent wrote: > >> Depending if you are using logrotate.d/audit and how it numbers the >> files as it rotates... >> >> audit.log.1.gz >> audit.log.2.gz >> ... >> audit.log.89.gz >> audit.log.90.gz >> >> The sort below will but the list in exact order.... >> >> zcat `ls /var/log/audit/*.gz | sort -t. --key=3,2n` | ausearch -i >> > > For this to work right, it has to be in descending order. So, add a -r to the > sort command. > > -Steve > > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Flatley Subject: Re: buffer space Date: Mon, 17 Aug 2009 17:18:02 -0400 Message-ID: References: <200908131428.52924.sgrubb@redhat.com> <200908171108.00417.sgrubb@redhat.com> <1250527972.3048.693.camel@homeserver> <1250529356.3048.700.camel@homeserver> <1250529871.3048.706.camel@homeserver> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2132381134==" Return-path: Received: from mx3.redhat.com (mx3.redhat.com [172.16.48.32]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n7HLIN7g024440 for ; Mon, 17 Aug 2009 17:18:23 -0400 Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by mx3.redhat.com (8.13.8/8.13.8) with ESMTP id n7HLI7Q9025864 for ; Mon, 17 Aug 2009 17:18:07 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n7HLA81U020752 for ; Mon, 17 Aug 2009 17:10:08 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n7HLI7wr256406 for ; Mon, 17 Aug 2009 17:18:07 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n7HLFEuE008701 for ; Mon, 17 Aug 2009 17:15:14 -0400 Received: from d01ml253.pok.ibm.com (d01ml253.pok.ibm.com [9.56.227.127]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n7HLFDTT008684 for ; Mon, 17 Aug 2009 17:15:14 -0400 In-Reply-To: <1250529871.3048.706.camel@homeserver> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: LC Bruzenak Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com --===============2132381134== Content-type: multipart/alternative; Boundary="0__=0ABBFC86DFE79B2D8f9e8a93df938690918c0ABBFC86DFE79B2D" Content-Disposition: inline --0__=0ABBFC86DFE79B2D8f9e8a93df938690918c0ABBFC86DFE79B2D Content-type: text/plain; charset=US-ASCII On Mon, 2009-08-17 at 12:15 -0500, LC Bruzenak wrote: > On Mon, 2009-08-17 at 13:06 -0400, David Flatley wrote: > > Lenny: > > > > I was going to move the rotated logs into /home/logs and use "ausearch > > -i -f /home/logs". > > > > > > David Flatley CISSP > > > > > > David, > > It won't work like that; exactly the issue I described: > > [root@slim root]# mkdir logs-test > [root@slim root]# cd !$ > cd logs-test > [root@slim logs-test]# auditctl -m "TEST message" > [root@slim logs-test]# service auditd rotate > Rotating logs: [ OK ] > [root@slim logs-test]# cp /var/log/audit/audit.log.1 . > [root@slim logs-test]# ausearch -i -f `pwd` -m USER > > [root@slim logs-test]# grep TEST audit.log.1 > node=slim type=USER msg=audit(1250529052.265:305135): user pid=8191 > uid=0 auid=500 ses=4172 subj=user_u:user_r:user_t:s0 msg='TEST message: > exe="/sbin/auditctl" (hostname=?, addr=?, terminal=pts/18 res=success)' > > > LCB. > David, I should have been more diligent. The input switch was supposed to be "-if" IIUC. The "-f" switch is looking for a filename inside the record. [root@slim logs-test]# ausearch -i -if `pwd` -m USER [root@slim logs-test]# ausearch -i -if `pwd`/audit.log.1 -m USER ... ---- node=slim type=USER msg=audit(08/17/2009 12:10:52.265:305135) : user pid=8191 uid=root auid=lcb ses=4172 subj=user_u:user_r:user_t:s0 msg='TEST message: exe=/sbin/auditctl (hostname=?, addr=?, terminal=pts/18 res=success)' ... This is what you want to do right - search inside a directory other than /var/log/audit with multiple audit logs inside the directory? LCB. Yes but not search for anything specific. Actually all I want to do is convert the logs from kernel text to regular notation (ausearch -i) to start with. I like Steve's idea of doing "service auditd rotate", then moving all the rotated logs to another directory to run the "ausearch -i" on the logs. This way auditd can keep running and processing the logs does not effect auditd. So what you did is pretty much what I want to do with the -if instead of just the -f. Thanks Lenny! David Flatley CISSP --0__=0ABBFC86DFE79B2D8f9e8a93df938690918c0ABBFC86DFE79B2D Content-type: text/html; charset=US-ASCII Content-Disposition: inline

On Mon, 2009-08-17 at 12:15 -0500, LC Bruzenak wrote:
> On Mon, 2009-08-17 at 13:06 -0400, David Flatley wrote:
> > Lenny:
> >
> > I was going to move the rotated logs into /home/logs and use "ausearch
> > -i -f /home/logs".
> >
> >
> > David Flatley CISSP
> >
> >
>
> David,
>
> It won't work like that; exactly the issue I described:
>
> [root@slim root]# mkdir logs-test
> [root@slim root]# cd !$
> cd logs-test
> [root@slim logs-test]# auditctl -m "TEST message"
> [root@slim logs-test]# service auditd rotate
> Rotating logs:                                             [  OK  ]
> [root@slim logs-test]# cp /var/log/audit/audit.log.1 .
> [root@slim logs-test]# ausearch -i -f `pwd` -m USER
> <no matches>
> [root@slim logs-test]# grep TEST audit.log.1
> node=slim type=USER msg=audit(1250529052.265:305135): user pid=8191
> uid=0 auid=500 ses=4172 subj=user_u:user_r:user_t:s0 msg='TEST message:
> exe="/sbin/auditctl" (hostname=?, addr=?, terminal=pts/18 res=success)'
>
>
> LCB.
>

David,

I should have been more diligent. The input switch was supposed to be
"-if" IIUC. The "-f" switch is looking for a filename inside the record.

[root@slim logs-test]# ausearch -i -if `pwd` -m USER
<no matches>

[root@slim logs-test]# ausearch -i -if `pwd`/audit.log.1  -m USER
...
----
node=slim type=USER msg=audit(08/17/2009 12:10:52.265:305135) : user
pid=8191 uid=root auid=lcb ses=4172 subj=user_u:user_r:user_t:s0
msg='TEST message: exe=/sbin/auditctl (hostname=?, addr=?,
terminal=pts/18 res=success)'
...

This is what you want to do right - search inside a directory other
than /var/log/audit with multiple audit logs inside the directory?

LCB.


   Yes but not search for anything specific. Actually all I want to do is convert the
logs from kernel text to regular notation (ausearch -i) to start with. I like Steve's
idea of doing "service auditd rotate", then moving all the rotated logs to another
directory to run the "ausearch -i" on the logs. This way auditd can keep running and
processing the logs does not effect auditd. So what you did is pretty much what I want
to do with the -if instead of just the -f.
  Thanks Lenny!


David Flatley CISSP
--0__=0ABBFC86DFE79B2D8f9e8a93df938690918c0ABBFC86DFE79B2D-- --===============2132381134== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============2132381134==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Flatley Subject: Re: buffer space Date: Tue, 18 Aug 2009 09:02:55 -0400 Message-ID: References: <1250532894.3048.729.camel@homeserver> <4A89A586.9020008@conceras.com> <200908171537.37593.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1290216178==" Return-path: In-Reply-To: <200908171537.37593.sgrubb@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: linux-audit@redhat.com, linux-audit-bounces@redhat.com List-Id: linux-audit@redhat.com --===============1290216178== Content-type: multipart/alternative; Boundary="0__=0ABBFC85DFD4A1E98f9e8a93df938690918c0ABBFC85DFD4A1E9" Content-Disposition: inline --0__=0ABBFC85DFD4A1E98f9e8a93df938690918c0ABBFC85DFD4A1E9 Content-type: text/plain; charset=US-ASCII When I do "service auditd rotate" I am getting in the /var/log/messages the following: Error receiving audit netlink packet (No buffer space available) Error sending signal_info request (No buffer space available) At the same time I am running a regression test that is generating 20 meg audit logs every six to eight minutes. Is this a concern? David Flatley --0__=0ABBFC85DFD4A1E98f9e8a93df938690918c0ABBFC85DFD4A1E9 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

When I do "service auditd rotate" I am getting in the /var/log/messages the following:

Error receiving audit netlink packet (No buffer space available)
Error sending signal_info request (No buffer space available)

At the same time I am running a regression test that is generating 20 meg audit logs every six to eight minutes.

Is this a concern?

David Flatley
--0__=0ABBFC85DFD4A1E98f9e8a93df938690918c0ABBFC85DFD4A1E9-- --===============1290216178== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============1290216178==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: LC Bruzenak Subject: Re: buffer space Date: Tue, 18 Aug 2009 10:09:58 -0500 Message-ID: <1250608198.3048.787.camel@homeserver> References: <1250532894.3048.729.camel@homeserver> <4A89A586.9020008@conceras.com> <200908171537.37593.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: David Flatley Cc: linux-audit-bounces@redhat.com, linux-audit@redhat.com List-Id: linux-audit@redhat.com On Tue, 2009-08-18 at 09:02 -0400, David Flatley wrote: > When I do "service auditd rotate" I am getting in > the /var/log/messages the following: > > Error receiving audit netlink packet (No buffer space available) > Error sending signal_info request (No buffer space available) > > At the same time I am running a regression test that is generating 20 > meg audit logs every six to eight minutes. > > Is this a concern? > > David Flatley > David, What I believe is happening is that you are generating an abnormal amount of audit data in your regression test. That's OK, but I think when you do the rotate the auditd suspends disk writes while it waits for the rotate to complete. IIRC, the rotate starts with the highest number log, rolls it to the next higher number. Then it decrements the counter and repeats. So log.13->log.14, then log.12->log.13, etc., and eventually moves audit.log to audit.log.1. Then a new audit.log is created and the flow resumes. While this happens, you are stacking up events from the kernel and eventually run out of space. On some machines where the log files are in the hundreds (I had around 300) I have seen the rotate take an appreciable amount of time. So you are probably dropping events when you get the above messages and I guess that is for you to decide if you are concerned about this for the duration of the test. This sounds like an instance of where you know that some application will generate huge amounts of AVC data you do not want to see in the logs, and ideally you would block those events with a rule. However, last week I believe, Steve noted that under the current kernel code (and probably auditctl rules) you cannot selectively exclude AVCs. LCB. -- LC (Lenny) Bruzenak lenny@magitekltd.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: buffer space Date: Tue, 18 Aug 2009 11:53:43 -0400 Message-ID: <200908181153.51387.sgrubb@redhat.com> References: <1250608198.3048.787.camel@homeserver> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1250608198.3048.787.camel@homeserver> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: LC Bruzenak Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Tuesday 18 August 2009 11:09:58 am LC Bruzenak wrote: > On Tue, 2009-08-18 at 09:02 -0400, David Flatley wrote: > > When I do "service auditd rotate" I am getting in > > the /var/log/messages the following: > > > > Error receiving audit netlink packet (No buffer space available) > > Error sending signal_info request (No buffer space available) > > > > At the same time I am running a regression test that is generating 20 > > meg audit logs every six to eight minutes. > > > > Is this a concern? It sounds like you have a system that is auditing a lot of data. Since you are doing regression testing, I would not be too concerned. But in general, you can increase the priority boost for auditd and see if it gets more time slots to drain the queue, make the log files larger, but fewer of them so rotate is faster, increase the backlog buffer some more, or adjust what you are auditing. > What I believe is happening is that you are generating an abnormal > amount of audit data in your regression test. That's OK, but I think > when you do the rotate the auditd suspends disk writes while it waits > for the rotate to complete. > > IIRC, the rotate starts with the highest number log, rolls it to the > next higher number. Then it decrements the counter and repeats. So > log.13->log.14, then log.12->log.13, etc., and eventually moves > audit.log to audit.log.1. Then a new audit.log is created and the flow > resumes. > > While this happens, you are stacking up events from the kernel and > eventually run out of space. On some machines where the log files are in > the hundreds (I had around 300) I have seen the rotate take an > appreciable amount of time. This is true. But having looked at the audit requirements and the given/suggested rules, they are badly in need of correction. I would say those audit rules is the root cause of the problem. -Steve From mboxrd@z Thu Jan 1 00:00:00 1970 From: "D.A. Muran-de Assereto" Subject: Re: buffer space Date: Sun, 23 Aug 2009 00:12:43 -0400 Message-ID: <20090823001243.54843yrlejzu1vy8@portal.tuad.org> References: <200908131428.52924.sgrubb@redhat.com> <200908171108.00417.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (ext-mx10.extmail.prod.ext.phx2.redhat.com [10.5.110.14]) by int-mx03.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n7N4CwQL001800 for ; Sun, 23 Aug 2009 00:12:59 -0400 Received: from dukecmmtar04.coxmail.com (dukecmmtar04.coxmail.com [68.99.120.47]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n7N4Cjf7022582 for ; Sun, 23 Aug 2009 00:12:45 -0400 Received: from portal.tuad.org ([68.106.145.250]) by dukecmmtar04.coxmail.com (InterMail vM.7.05.02.00 201-2174-114-20060621) with ESMTP id <20090823040537.VEYC13010.dukecmmtar04.coxmail.com@portal.tuad.org> for ; Sun, 23 Aug 2009 00:05:37 -0400 Received: from portal.tuad.org (localhost [127.0.0.1]) by portal.tuad.org (8.14.3/8.14.3) with ESMTP id n7N4Ch9s077355 for ; Sun, 23 Aug 2009 00:12:43 -0400 (EDT) (envelope-from dmuran@tuad.org) Received: (from www@localhost) by portal.tuad.org (8.14.3/8.14.3/Submit) id n7N4ChG6077354 for linux-audit@redhat.com; Sun, 23 Aug 2009 00:12:43 -0400 (EDT) (envelope-from dmuran@tuad.org) In-Reply-To: <200908171108.00417.sgrubb@redhat.com> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com List-Id: linux-audit@redhat.com Quoting Steve Grubb : > On Monday 17 August 2009 10:49:55 am David Flatley wrote: >> 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? No, there are not. The SECSCN Linux audit checking module was something I hacked together in a vacuum a couple of years ago. The "theory" was to try to satisfy DCID 6/3 auditing requirements at the time. Not sure if the code has been modified since then; it was a "best guess, first cut" standard at the time. I am checking with the current development team to see if they've made any significant changes since then. Dave Muran-de Assereto From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Muran-de Assereto Subject: Re: buffer space Date: Sun, 23 Aug 2009 00:32:23 -0400 Message-ID: <79E985B3-3176-478F-B4F9-D538BC0B33D3@tuad.org> References: <200908131428.52924.sgrubb@redhat.com> <4A897884.6030703@conceras.com> Mime-Version: 1.0 (Apple Message framework v936) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (ext-mx06.extmail.prod.ext.phx2.redhat.com [10.5.110.10]) by int-mx06.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n7N4Wc7A029096 for ; Sun, 23 Aug 2009 00:32:38 -0400 Received: from dukecmmtar04.coxmail.com (dukecmmtar04.coxmail.com [68.99.120.47]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n7N4WOY0001344 for ; Sun, 23 Aug 2009 00:32:25 -0400 In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Mike Nixon Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Aug 17, 2009, at 12:58 , Mike Nixon wrote: > Attached are is the audit.rules file from SECSCN 4.3. There is a > v4.4 now > available but I don't have it handy. Also attached are two docs which > explain SECSCN's auditd configuration expectations. > > -Mike > Yeah, the audit.rules that you have there is the test version that I hacked together more than two years ago as a "first cut". It includes a lot of stuff which might or might have not been installed or needed, just on the off chance. The intent there was to discuss the rules requirements with your certifier, not to take them as gospel. That stuff should have been reviewed some time ago. I will be glad to refer specific concerns or recommended fixes to the current development team. Lenny, you should have dropped me a line about this thread. I only casually monitor this list, and happened upon it by chance. Dave Muran-de Assereto > On Mon, Aug 17, 2009 at 11:34 AM, Norman Mark St. Laurent < > mstlaurent@conceras.com> wrote: > >> Hi David, >> >> I too would like to know what version of SECSCAN you are using for >> the >> "required watches". I run the STIGS, SECSCAN, and a myriad of >> vulnerability >> analysis tools (outside looking in --> inside looking around) on >> systems >> that I ISSE and provision. I do not recall "required watches" that >> need to >> be set with this tool, but I maybe off a version and I may need to >> visit >> another sight to pick up the latest and greatest.... >> >> I know SECSCAN would like the System to be configured to HALT on >> audit >> failure using the disk_ful_action_setting in /etc/audit/ >> auditd.conf. It >> would also like the system to be configured to halt on audit disk >> error as >> well as the audit data to be synchronously flushed to disk to avoid >> data >> loss. To do this (respectfully) I have set in my KickStarts and >> Satellite: >> >> perl -npe 's/disk_full_action = SUSPEND/disk_full_action = HALT/' -i >> /etc/audit/auditd.conf >> perl -npe 's/disk_error_action = SUSPEND/disk_error_action = HALT/' >> -i >> /etc/audit/auditd.conf >> perl -npe 's/flush = INCREMENTAL/flush = SYNC/' -i /etc/audit/ >> auditd.conf >> >> Currently I set the /var/log/audit logs to rotate daily for 90 >> days... in >> /etc/logrotate.d/audit and the capp.rules ; nispom.rules in >> /usr/share/doc/audit* all work great and provide nice examples to >> comply >> with Security Policy. >> >> Because of the logrotation and the way aureport works, I have >> written a >> wrapper script to be able to search and report all the log files. >> Something >> of this type would help the Security Officers look threw the log >> files. The >> script also keeps a pristine copy of the log files for >> investigation with >> digital sigs to watch the tampering (as well as aide) for >> investigation if >> need be --> this keeps processing the files (MAC Times) and a >> pristine copy >> separated. >> >> I am very interested in finding our more about these set watches >> that are >> required in SECSCAN. >> >> Best regards, >> >> >> Norman Mark St. Laurent >> Conceras | Chief Technology Officer and ISSE >> >> >> >> David Flatley wrote: >> >>> >>> Thanks Steve! >>> 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? >>> >>> Backlog is set to 12288 right now. >>> >>> 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". >>> Because I was getting errors restarting the auditd on some of their >>> recommendations one of which was mount? >>> >>> 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. >>> >>> 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? I would set the >>> max rotated logs to 10 to allow the new rotated log space then >>> move the >>> logs as you suggest. >>> >>> Thanks. >>> >>> David Flatley CISSP >>> >>> >>> >>> >>> Inactive hide details for Steve Grubb ---08/13/2009 02:29:34 PM---On >>> Thursday 13 August 2009 10:56:50 am David Flatley wrote: > Steve >>> Grubb >>> ---08/13/2009 02:29:34 PM---On Thursday 13 August 2009 10:56:50 am >>> David >>> Flatley wrote: > Red Hat 5.3 running audit 1.7.7-6 >>> >>> >>> From: >>> Steve Grubb >>> >>> To: >>> linux-audit@redhat.com >>> >>> Cc: >>> David Flatley/Burlington/IBM@IBMUS >>> >>> Date: >>> 08/13/2009 02:29 PM >>> >>> Subject: >>> Re: buffer space >>> >>> >>> >>> >>> On Thursday 13 August 2009 10:56:50 am David Flatley wrote: >>>> Red Hat 5.3 running audit 1.7.7-6 >>>> Rotating logs at 20 megs and allowing 8 logs >>>> Rules have watches and syscalls from the SECSCAN recommendations, >>>> and >>> have >>>> added some of Steve Grubb's recommendations. >>> >>> I would be curious what the SECSCAN recommendations are. Never >>> heard of >>> it... >>> >>> >>>> When we extract and archive the audit logs we get "Error >>>> receiving audit >>>> netlink packet (No buffer space available) an "error sending >>>> signal info >>>> request" >>>> Our extract is: stop auditd then create a file and run ausearch - >>>> i > >>> file >>>> then run an aureport -i > file then once that is done we delete >>>> all the >>>> logs and restart auditd. >>> >>> I think this is your problem. If you have audit rules loaded and >>> stop >>> auditd, >>> then audit events are going to pile up in the queue waiting for >>> auditd to >>> download them. At some point the kernel will decide auditd doesn't >>> exist >>> and >>> will dump all events to syslog. This probably is not what you want >>> either. >>> >>> I would recommend calling "service auditd rotate" and then grab logs >>> audit.log.1 -> audit.logs.7 and move them away to another >>> directory for >>> post processing the contents. >>> >>> You may also want to check you backlog size settings too. >>> >>> >>>> If I run this manually it works fine but if I have it running it >>>> in a >>> cron >>>> we get Kernel panics, lockups and log data loss plus the buffer >>> messages. >>> >>> Shouldn't really make a difference. >>> >>> -Steve >>> >>> >>> ------------------------------------------------------------------------ >>> >>> -- >>> Linux-audit mailing list >>> Linux-audit@redhat.com >>> https://www.redhat.com/mailman/listinfo/linux-audit >>> >> >> -- >> Linux-audit mailing list >> Linux-audit@redhat.com >> https://www.redhat.com/mailman/listinfo/linux-audit >> > -- > Linux-audit mailing list > Linux-audit@redhat.com > https://www.redhat.com/mailman/listinfo/linux-audit David Muran-de Assereto dmuran@tuad.org XML is like violence: if it doesn't solve your problem, you're not using enough of it. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Nixon Subject: Re: buffer space Date: Sun, 23 Aug 2009 12:12:27 -0400 Message-ID: References: <200908131428.52924.sgrubb@redhat.com> <4A897884.6030703@conceras.com> <79E985B3-3176-478F-B4F9-D538BC0B33D3@tuad.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1620189165==" Return-path: Received: from mx1.redhat.com (ext-mx01.extmail.prod.ext.phx2.redhat.com [10.5.110.5]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n7NGCfnO006685 for ; Sun, 23 Aug 2009 12:12:41 -0400 Received: from mail-fx0-f221.google.com (mail-fx0-f221.google.com [209.85.220.221]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n7NGCUU6029977 for ; Sun, 23 Aug 2009 12:12:31 -0400 Received: by fxm21 with SMTP id 21so1105159fxm.3 for ; Sun, 23 Aug 2009 09:12:30 -0700 (PDT) In-Reply-To: <79E985B3-3176-478F-B4F9-D538BC0B33D3@tuad.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: David Muran-de Assereto Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com --===============1620189165== Content-Type: multipart/alternative; boundary=001517447dc619fde70471d15e86 --001517447dc619fde70471d15e86 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Unfortunately your 'test version' rules are being used in the production version releases of SECSCN. As I mentioned before, those rules came from SECSCN version 4.3. Version 4.4 is now available but I strongly suspect that the rules are the same in both versions. Even more unfortunate, many C&A reps demand 'compliance' with SECSCN recommendations and insist that those rules are implemented exactly as written. My colleagues and I spend a lot of time, effort and (*taxpayer*) dollars trying to convince certifiers and accreditors that the rules as written are not appropriate for operational systems and must be modified to avoid adversely impacting functionality. The law of unintended consequences demands that no good deed goes unpunished. I appreciate whatever work you contributed to developing SECSCN I just wish there was some documentation, from an authoritative source, that instructed compliance personnel about the importance and necessity of customized configurations. -Mike Nixon, CISSP LTC Engineering Associates, Inc. On Sun, Aug 23, 2009 at 12:32 AM, David Muran-de Assereto wrote: > > On Aug 17, 2009, at 12:58 , Mike Nixon wrote: > > Attached are is the audit.rules file from SECSCN 4.3. There is a v4.4 now >> available but I don't have it handy. Also attached are two docs which >> explain SECSCN's auditd configuration expectations. >> >> -Mike >> >> > Yeah, the audit.rules that you have there is the test version that I hacked > together more than two years ago as a "first cut". > It includes a lot of stuff which might or might have not been installed or > needed, just on the off chance. The intent there was to discuss the rules > requirements with your certifier, not to take them as gospel. > That stuff should have been reviewed some time ago. I will be glad to refer > specific concerns or recommended fixes to the current development team. > > Lenny, you should have dropped me a line about this thread. I only casually > monitor this list, and happened upon it by chance. > > Dave Muran-de Assereto > > > On Mon, Aug 17, 2009 at 11:34 AM, Norman Mark St. Laurent < >> mstlaurent@conceras.com> wrote: >> >> Hi David, >>> >>> I too would like to know what version of SECSCAN you are using for the >>> "required watches". I run the STIGS, SECSCAN, and a myriad of >>> vulnerability >>> analysis tools (outside looking in --> inside looking around) on systems >>> that I ISSE and provision. I do not recall "required watches" that need >>> to >>> be set with this tool, but I maybe off a version and I may need to visit >>> another sight to pick up the latest and greatest.... >>> >>> I know SECSCAN would like the System to be configured to HALT on audit >>> failure using the disk_ful_action_setting in /etc/audit/auditd.conf. It >>> would also like the system to be configured to halt on audit disk error >>> as >>> well as the audit data to be synchronously flushed to disk to avoid data >>> loss. To do this (respectfully) I have set in my KickStarts and >>> Satellite: >>> >>> perl -npe 's/disk_full_action = SUSPEND/disk_full_action = HALT/' -i >>> /etc/audit/auditd.conf >>> perl -npe 's/disk_error_action = SUSPEND/disk_error_action = HALT/' -i >>> /etc/audit/auditd.conf >>> perl -npe 's/flush = INCREMENTAL/flush = SYNC/' -i /etc/audit/auditd.conf >>> >>> Currently I set the /var/log/audit logs to rotate daily for 90 days... >>> in >>> /etc/logrotate.d/audit and the capp.rules ; nispom.rules in >>> /usr/share/doc/audit* all work great and provide nice examples to comply >>> with Security Policy. >>> >>> Because of the logrotation and the way aureport works, I have written a >>> wrapper script to be able to search and report all the log files. >>> Something >>> of this type would help the Security Officers look threw the log files. >>> The >>> script also keeps a pristine copy of the log files for investigation with >>> digital sigs to watch the tampering (as well as aide) for investigation >>> if >>> need be --> this keeps processing the files (MAC Times) and a pristine >>> copy >>> separated. >>> >>> I am very interested in finding our more about these set watches that are >>> required in SECSCAN. >>> >>> Best regards, >>> >>> >>> Norman Mark St. Laurent >>> Conceras | Chief Technology Officer and ISSE >>> >>> >>> >>> David Flatley wrote: >>> >>> >>>> Thanks Steve! >>>> 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? >>>> >>>> Backlog is set to 12288 right now. >>>> >>>> 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". >>>> Because I was getting errors restarting the auditd on some of their >>>> recommendations one of which was mount? >>>> >>>> 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. >>>> >>>> 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? I would set the >>>> max rotated logs to 10 to allow the new rotated log space then move the >>>> logs as you suggest. >>>> >>>> Thanks. >>>> >>>> David Flatley CISSP >>>> >>>> >>>> >>>> >>>> Inactive hide details for Steve Grubb ---08/13/2009 02:29:34 PM---On >>>> Thursday 13 August 2009 10:56:50 am David Flatley wrote: > Steve Grubb >>>> ---08/13/2009 02:29:34 PM---On Thursday 13 August 2009 10:56:50 am David >>>> Flatley wrote: > Red Hat 5.3 running audit 1.7.7-6 >>>> >>>> >>>> From: >>>> Steve Grubb >>>> >>>> To: >>>> linux-audit@redhat.com >>>> >>>> Cc: >>>> David Flatley/Burlington/IBM@IBMUS >>>> >>>> Date: >>>> 08/13/2009 02:29 PM >>>> >>>> Subject: >>>> Re: buffer space >>>> >>>> >>>> >>>> >>>> On Thursday 13 August 2009 10:56:50 am David Flatley wrote: >>>> >>>>> Red Hat 5.3 running audit 1.7.7-6 >>>>> Rotating logs at 20 megs and allowing 8 logs >>>>> Rules have watches and syscalls from the SECSCAN recommendations, and >>>>> >>>> have >>>> >>>>> added some of Steve Grubb's recommendations. >>>>> >>>> >>>> I would be curious what the SECSCAN recommendations are. Never heard of >>>> it... >>>> >>>> >>>> When we extract and archive the audit logs we get "Error receiving >>>>> audit >>>>> netlink packet (No buffer space available) an "error sending signal >>>>> info >>>>> request" >>>>> Our extract is: stop auditd then create a file and run ausearch -i > >>>>> >>>> file >>>> >>>>> then run an aureport -i > file then once that is done we delete all the >>>>> logs and restart auditd. >>>>> >>>> >>>> I think this is your problem. If you have audit rules loaded and stop >>>> auditd, >>>> then audit events are going to pile up in the queue waiting for auditd >>>> to >>>> download them. At some point the kernel will decide auditd doesn't exist >>>> and >>>> will dump all events to syslog. This probably is not what you want >>>> either. >>>> >>>> I would recommend calling "service auditd rotate" and then grab logs >>>> audit.log.1 -> audit.logs.7 and move them away to another directory for >>>> post processing the contents. >>>> >>>> You may also want to check you backlog size settings too. >>>> >>>> >>>> If I run this manually it works fine but if I have it running it in a >>>>> >>>> cron >>>> >>>>> we get Kernel panics, lockups and log data loss plus the buffer >>>>> >>>> messages. >>>> >>>> Shouldn't really make a difference. >>>> >>>> -Steve >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> -- >>>> Linux-audit mailing list >>>> Linux-audit@redhat.com >>>> https://www.redhat.com/mailman/listinfo/linux-audit >>>> >>>> >>> -- >>> Linux-audit mailing list >>> Linux-audit@redhat.com >>> https://www.redhat.com/mailman/listinfo/linux-audit >>> >>> -- >> Linux-audit mailing list >> Linux-audit@redhat.com >> https://www.redhat.com/mailman/listinfo/linux-audit >> > > David Muran-de Assereto > dmuran@tuad.org > > XML is like violence: if it doesn't solve your problem, you're not using > enough of it. > > --001517447dc619fde70471d15e86 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Unfortunately your 'test version' rules are being used in the produ= ction version releases of SECSCN. =A0As I mentioned before, those rules cam= e from SECSCN version 4.3. Version 4.4 is now available but I strongly susp= ect that the rules are the same in both versions. =A0Even more unfortunate,= many C&A reps demand 'compliance' with SECSCN recommendations = and insist that those rules are implemented exactly as written. =A0My=A0col= leagues=A0and I spend a lot of time, effort and (taxpayer) dollars t= rying to=A0convince certifiers and accreditors that the rules as written ar= e not appropriate for operational systems and must be modified to avoid adv= ersely impacting functionality.


The law of unintended consequences demands that no good deed= goes unpunished. =A0I=A0appreciate=A0whatever work you contributed to deve= loping SECSCN I just wish there was some documentation, from an=A0authorita= tive=A0source, that instructed=A0compliance=A0personnel about the importanc= e and necessity of customized configurations.

-Mike Nixon, CISSP
LTC Engineering Associates= , Inc.

On Sun, Aug 23, 2009 at 12:= 32 AM, David Muran-de Assereto <dmuran@tuad.org> wrote:

On Aug 17, 2009, at 12:58 , Mike Nixon wrote:

Attached are is the audit.rules file from SECSCN 4.3. =A0There is a v4.4 no= w
available but I don't have it handy. =A0Also attached are two docs whic= h
explain SECSCN's auditd configuration expectations.

-Mike


Yeah, the audit.rules that you have there is the test version that I hacked= together more than two years ago as a "first cut".
It includes a lot of stuff which might or might have not been installed or = needed, just on the off chance. The intent there was to discuss the rules r= equirements with your certifier, not to take them as gospel.
That stuff should have been reviewed some time ago. I will be glad to refer= specific concerns or recommended fixes to the current development team.
Lenny, you should have dropped me a line about this thread. I only casually= monitor this list, and happened upon it by chance.

Dave Muran-de Assereto


On Mon, Aug 17, 2009 at 11:34 AM, Norman Mark St. Laurent <
mstlaurent@con= ceras.com> wrote:

Hi David,

I too would like to know what version of SECSCAN you are using for the
"required watches". =A0I run the STIGS, SECSCAN, and a myriad of = vulnerability
analysis tools (outside looking in --> =A0inside looking around) on syst= ems
that I ISSE and provision. =A0I do not recall "required watches" = that need to
be set with this tool, but I maybe off a version and I may need to visit another sight to pick up the latest and greatest....

I know SECSCAN would like the System to be configured to HALT on audit
failure using the disk_ful_action_setting in /etc/audit/auditd.conf. =A0It<= br> would also like the system to be configured to halt on audit disk error as<= br> well as the audit data to be synchronously flushed to disk to avoid data loss. =A0To do this (respectfully) I have set in my KickStarts and Satellit= e:

perl -npe 's/disk_full_action =3D SUSPEND/disk_full_action =3D HALT/= 9; -i
/etc/audit/auditd.conf
perl -npe 's/disk_error_action =3D SUSPEND/disk_error_action =3D HALT/&= #39; -i
/etc/audit/auditd.conf
perl -npe 's/flush =3D INCREMENTAL/flush =3D SYNC/' -i /etc/audit/a= uditd.conf

Currently I set the /var/log/audit logs to rotate daily for 90 days... =A0i= n
/etc/logrotate.d/audit =A0and the capp.rules ; nispom.rules in
/usr/share/doc/audit* all work great and provide nice examples to comply with Security Policy.

Because of the logrotation and the way aureport works, I have written a
wrapper script to be able to search and report all the log files. =A0Someth= ing
of this type would help the Security Officers look threw the log files. =A0= The
script also keeps a pristine copy of the log files for investigation with digital sigs to watch the tampering =A0(as well as aide) for investigation = if
need be --> this keeps processing the files (MAC Times) and a pristine c= opy
separated.

I am very interested in finding our more about these set watches that are required in SECSCAN.

Best regards,


Norman Mark St. Laurent
Conceras | Chief Technology Officer and ISSE



David Flatley wrote:


Thanks Steve!
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?

Backlog is set to 12288 right now.


The SECSCAN requires many -w (watches) and a fair amount of syscalls. I
modified the syscalls to add your recommendation for using "arch=3Db32= " and
"arch=3Db64".
Because I was getting errors restarting the auditd on some of their
recommendations one of which was mount?

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.

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<= br> working? I would set the
max rotated logs to 10 to allow the new rotated log space then move the
logs as you suggest.

Thanks.

David Flatley CISSP




Inactive hide details for Steve Grubb ---08/13/2009 02:29:34 PM---On
Thursday 13 August 2009 10:56:50 am David Flatley wrote: > Steve Grubb ---08/13/2009 02:29:34 PM---On Thursday 13 August 2009 10:56:50 am David Flatley wrote: > Red Hat 5.3 running audit 1.7.7-6


From:

Steve Grubb <sgru= bb@redhat.com>

To:
linux-audit@red= hat.com

Cc:
David Flatley/Burlington/IBM@IBMUS

Date:
08/13/2009 02:29 PM

Subject:
Re: buffer space




On Thursday 13 August 2009 10:56:50 am David Flatley wrote:
=A0Red Hat 5.3 running audit 1.7.7-6
Rotating logs at 20 megs and allowing 8 logs
Rules have watches and syscalls from the SECSCAN recommendations, and
have
added some of Steve Grubb's recommendations.

I would be curious what the SECSCAN recommendations are. Never heard of
it...


When we extract and archive the audit logs we get "Error receiving aud= it
netlink packet (No buffer space available) an "error sending signal in= fo
request"
Our extract is: stop auditd then create a file and run ausearch -i >
file
then run an aureport -i > file then once that is done we delete all the<= br> logs and restart auditd.

I think this is your problem. If you have audit rules loaded and stop
auditd,
then audit events are going to pile up in the queue waiting for auditd to download them. At some point the kernel will decide auditd doesn't exis= t
and
will dump all events to syslog. This probably is not what you want either.<= br>
I would recommend calling "service auditd rotate" and then grab l= ogs
audit.log.1 -> audit.logs.7 and move them away to another directory for<= br> post =A0processing the contents.

You may also want to check you backlog size settings too.


If I run this manually it works fine but if I have it running it in a
cron
we get Kernel panics, lockups and log data loss plus the buffer
messages.

Shouldn't really make a difference.

-Steve


------------------------------------------------------------------------

--
Linux-audit mailing list
Linux-audit@red= hat.com
https://www.redhat.com/mailman/listinfo/linux-audit

<AUDIT1.HTML><AUDIT.RULES><AUDITDESCRIP.HTML>--
David Muran-de Assereto
dmuran@tuad.org
XML is like violence: if it doesn't solve your problem, you're not = using enough of it.


--001517447dc619fde70471d15e86-- --===============1620189165== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============1620189165==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Muran-de Assereto Subject: Re: buffer space Date: Sun, 23 Aug 2009 16:24:06 -0400 Message-ID: <55399510-44DD-487D-9706-23B8FC13B6F2@tuad.org> References: <200908131428.52924.sgrubb@redhat.com> <4A897884.6030703@conceras.com> <79E985B3-3176-478F-B4F9-D538BC0B33D3@tuad.org> Mime-Version: 1.0 (Apple Message framework v936) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (ext-mx02.extmail.prod.ext.phx2.redhat.com [10.5.110.6]) by int-mx04.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n7NKOLqh016282 for ; Sun, 23 Aug 2009 16:24:21 -0400 Received: from dukecmmtar04.coxmail.com (dukecmmtar04.coxmail.com [68.99.120.47]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n7NKO8nw020099 for ; Sun, 23 Aug 2009 16:24:08 -0400 In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Mike Nixon Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com (Top Post, sorry) I gathered all that from the discussion, although I came to it late, and am talking to the current developers to see what can be done about it. I am just as opposed to wasting taxpayers dollars as you are, and am sorry that SECSCN is being treated the same way as the SRR is treated in the DoD community. There is documentation from authoritative sources discussing variances and custom configurations; all of the IC C&A compliance guidance I am familiar with covers those points. At least in the DoDIIS and DNI communities, we routinely accredit systems based on an understanding of the total risk environment, and in my experience, do not adhere slavishly to the output of a tool. More to the point, the new NIST 800-53-based process should be even more responsive to your needs while still ensuring that appropriate security controls are in place. That, in itself, however, will not fix problems with tools. The "test" ruleset, especially file watches, was put together based on regulatory auditing requirements for system configuration files, and purposely covers all the ones I could think of and had seen on deployed systems. Generally, if a file is not specifically called out by tool or test engineer it is not audited; that goes double for files from uncommon system daemons or servers. Thus, the output was supposed to stimulate conversation between system developers/integrators and the less- technical certifiers. In the absence of a qualified test engineer, I don't really see any other way to do an assessment of the system; whatever tool is used has to be able to look for things which a certifier will not know to look for. To reiterate, the intent of SECSCN is not and was never to produce a Mosaic pronouncement of law. The SECSCN "code" itself is naive, and should perform more analysis before uttering pronouncements. This naivete is the direct result of it being a largely unfunded effort put together to serve a perceived need. I live in the fervent hope that the C&A community, having recognized the value of the tool, will make it into a formal program and fund it. Dave Muran-de Assereto Technical Lead DNI CAT On Aug 23, 2009, at 12:12 , Mike Nixon wrote: > Unfortunately your 'test version' rules are being used in the > production > version releases of SECSCN. As I mentioned before, those rules came > from > SECSCN version 4.3. Version 4.4 is now available but I strongly > suspect that > the rules are the same in both versions. Even more unfortunate, > many C&A > reps demand 'compliance' with SECSCN recommendations and insist that > those > rules are implemented exactly as written. My colleagues and I spend > a lot > of time, effort and (*taxpayer*) dollars trying to convince > certifiers and > accreditors that the rules as written are not appropriate for > operational > systems and must be modified to avoid adversely impacting > functionality. > The law of unintended consequences demands that no good deed goes > unpunished. I appreciate whatever work you contributed to > developing SECSCN > I just wish there was some documentation, from an authoritative > source, that > instructed compliance personnel about the importance and necessity of > customized configurations. > > -Mike Nixon, CISSP > LTC Engineering Associates, Inc. > > On Sun, Aug 23, 2009 at 12:32 AM, David Muran-de Assereto > wrote: > >> >> On Aug 17, 2009, at 12:58 , Mike Nixon wrote: >> >> Attached are is the audit.rules file from SECSCN 4.3. There is a >> v4.4 now >>> available but I don't have it handy. Also attached are two docs >>> which >>> explain SECSCN's auditd configuration expectations. >>> >>> -Mike >>> >>> >> Yeah, the audit.rules that you have there is the test version that >> I hacked >> together more than two years ago as a "first cut". >> It includes a lot of stuff which might or might have not been >> installed or >> needed, just on the off chance. The intent there was to discuss the >> rules >> requirements with your certifier, not to take them as gospel. >> That stuff should have been reviewed some time ago. I will be glad >> to refer >> specific concerns or recommended fixes to the current development >> team. >> >> Lenny, you should have dropped me a line about this thread. I only >> casually >> monitor this list, and happened upon it by chance. >> >> Dave Muran-de Assereto >> >> >> On Mon, Aug 17, 2009 at 11:34 AM, Norman Mark St. Laurent < >>> mstlaurent@conceras.com> wrote: >>> >>> Hi David, >>>> >>>> I too would like to know what version of SECSCAN you are using >>>> for the >>>> "required watches". I run the STIGS, SECSCAN, and a myriad of >>>> vulnerability >>>> analysis tools (outside looking in --> inside looking around) on >>>> systems >>>> that I ISSE and provision. I do not recall "required watches" >>>> that need >>>> to >>>> be set with this tool, but I maybe off a version and I may need >>>> to visit >>>> another sight to pick up the latest and greatest.... >>>> >>>> I know SECSCAN would like the System to be configured to HALT on >>>> audit >>>> failure using the disk_ful_action_setting in /etc/audit/ >>>> auditd.conf. It >>>> would also like the system to be configured to halt on audit disk >>>> error >>>> as >>>> well as the audit data to be synchronously flushed to disk to >>>> avoid data >>>> loss. To do this (respectfully) I have set in my KickStarts and >>>> Satellite: >>>> >>>> perl -npe 's/disk_full_action = SUSPEND/disk_full_action = HALT/' >>>> -i >>>> /etc/audit/auditd.conf >>>> perl -npe 's/disk_error_action = SUSPEND/disk_error_action = >>>> HALT/' -i >>>> /etc/audit/auditd.conf >>>> perl -npe 's/flush = INCREMENTAL/flush = SYNC/' -i /etc/audit/ >>>> auditd.conf >>>> >>>> Currently I set the /var/log/audit logs to rotate daily for 90 >>>> days... >>>> in >>>> /etc/logrotate.d/audit and the capp.rules ; nispom.rules in >>>> /usr/share/doc/audit* all work great and provide nice examples to >>>> comply >>>> with Security Policy. >>>> >>>> Because of the logrotation and the way aureport works, I have >>>> written a >>>> wrapper script to be able to search and report all the log files. >>>> Something >>>> of this type would help the Security Officers look threw the log >>>> files. >>>> The >>>> script also keeps a pristine copy of the log files for >>>> investigation with >>>> digital sigs to watch the tampering (as well as aide) for >>>> investigation >>>> if >>>> need be --> this keeps processing the files (MAC Times) and a >>>> pristine >>>> copy >>>> separated. >>>> >>>> I am very interested in finding our more about these set watches >>>> that are >>>> required in SECSCAN. >>>> >>>> Best regards, >>>> >>>> >>>> Norman Mark St. Laurent >>>> Conceras | Chief Technology Officer and ISSE >>>> >>>> >>>> >>>> David Flatley wrote: >>>> >>>> >>>>> Thanks Steve! >>>>> 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? >>>>> >>>>> Backlog is set to 12288 right now. >>>>> >>>>> 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". >>>>> Because I was getting errors restarting the auditd on some of >>>>> their >>>>> recommendations one of which was mount? >>>>> >>>>> 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. >>>>> >>>>> 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? I would set the >>>>> max rotated logs to 10 to allow the new rotated log space then >>>>> move the >>>>> logs as you suggest. >>>>> >>>>> Thanks. >>>>> >>>>> David Flatley CISSP >>>>> >>>>> >>>>> >>>>> >>>>> Inactive hide details for Steve Grubb ---08/13/2009 02:29:34 >>>>> PM---On >>>>> Thursday 13 August 2009 10:56:50 am David Flatley wrote: > Steve >>>>> Grubb >>>>> ---08/13/2009 02:29:34 PM---On Thursday 13 August 2009 10:56:50 >>>>> am David >>>>> Flatley wrote: > Red Hat 5.3 running audit 1.7.7-6 >>>>> >>>>> >>>>> From: >>>>> Steve Grubb >>>>> >>>>> To: >>>>> linux-audit@redhat.com >>>>> >>>>> Cc: >>>>> David Flatley/Burlington/IBM@IBMUS >>>>> >>>>> Date: >>>>> 08/13/2009 02:29 PM >>>>> >>>>> Subject: >>>>> Re: buffer space >>>>> >>>>> >>>>> >>>>> >>>>> On Thursday 13 August 2009 10:56:50 am David Flatley wrote: >>>>> >>>>>> Red Hat 5.3 running audit 1.7.7-6 >>>>>> Rotating logs at 20 megs and allowing 8 logs >>>>>> Rules have watches and syscalls from the SECSCAN >>>>>> recommendations, and >>>>>> >>>>> have >>>>> >>>>>> added some of Steve Grubb's recommendations. >>>>>> >>>>> >>>>> I would be curious what the SECSCAN recommendations are. Never >>>>> heard of >>>>> it... >>>>> >>>>> >>>>> When we extract and archive the audit logs we get "Error receiving >>>>>> audit >>>>>> netlink packet (No buffer space available) an "error sending >>>>>> signal >>>>>> info >>>>>> request" >>>>>> Our extract is: stop auditd then create a file and run ausearch >>>>>> -i > >>>>>> >>>>> file >>>>> >>>>>> then run an aureport -i > file then once that is done we delete >>>>>> all the >>>>>> logs and restart auditd. >>>>>> >>>>> >>>>> I think this is your problem. If you have audit rules loaded and >>>>> stop >>>>> auditd, >>>>> then audit events are going to pile up in the queue waiting for >>>>> auditd >>>>> to >>>>> download them. At some point the kernel will decide auditd >>>>> doesn't exist >>>>> and >>>>> will dump all events to syslog. This probably is not what you want >>>>> either. >>>>> >>>>> I would recommend calling "service auditd rotate" and then grab >>>>> logs >>>>> audit.log.1 -> audit.logs.7 and move them away to another >>>>> directory for >>>>> post processing the contents. >>>>> >>>>> You may also want to check you backlog size settings too. >>>>> >>>>> >>>>> If I run this manually it works fine but if I have it running it >>>>> in a >>>>>> >>>>> cron >>>>> >>>>>> we get Kernel panics, lockups and log data loss plus the buffer >>>>>> >>>>> messages. >>>>> >>>>> Shouldn't really make a difference. >>>>> >>>>> -Steve >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> -- >>>>> Linux-audit mailing list >>>>> Linux-audit@redhat.com >>>>> https://www.redhat.com/mailman/listinfo/linux-audit >>>>> >>>>> >>>> -- >>>> Linux-audit mailing list >>>> Linux-audit@redhat.com >>>> https://www.redhat.com/mailman/listinfo/linux-audit >>>> >>>> -- >>> Linux-audit mailing list >>> Linux-audit@redhat.com >>> https://www.redhat.com/mailman/listinfo/linux-audit >>> >> >> David Muran-de Assereto >> dmuran@tuad.org >> >> XML is like violence: if it doesn't solve your problem, you're not >> using >> enough of it. >> >> David Muran-de Assereto dmuran@tuad.org XML is like violence: if it doesn't solve your problem, you're not using enough of it. From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Flatley Subject: Re: buffer space Date: Thu, 27 Aug 2009 13:21:43 -0400 Message-ID: References: <1250532894.3048.729.camel@homeserver> <4A89A586.9020008@conceras.com> <200908171537.37593.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1478405785==" Return-path: In-Reply-To: <200908171537.37593.sgrubb@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: linux-audit@redhat.com, linux-audit-bounces@redhat.com List-Id: linux-audit@redhat.com --===============1478405785== Content-type: multipart/alternative; Boundary="0__=0ABBFC8CDFCDC1018f9e8a93df938690918c0ABBFC8CDFCDC101" Content-Disposition: inline --0__=0ABBFC8CDFCDC1018f9e8a93df938690918c0ABBFC8CDFCDC101 Content-type: text/plain; charset=US-ASCII When auditd starts and reports an error on a line in the audit.rules, does auditd continue to run with the rest of the rules? Or does auditd stop waiting for a correction to the rules file? An example would be on syscalls for fchown32 or umount. Thanks. David Flatley CISSP --0__=0ABBFC8CDFCDC1018f9e8a93df938690918c0ABBFC8CDFCDC101 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

When auditd starts and reports an error on a line in the audit.rules, does auditd continue to run with the rest of the rules?
Or does auditd stop waiting for a correction to the rules file? An example would be on syscalls for fchown32 or umount.
Thanks.


David Flatley CISSP

--0__=0ABBFC8CDFCDC1018f9e8a93df938690918c0ABBFC8CDFCDC101-- --===============1478405785== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============1478405785==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: buffer space Date: Thu, 27 Aug 2009 13:32:20 -0400 Message-ID: <200908271332.20237.sgrubb@redhat.com> References: <200908171537.37593.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: David Flatley Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Thursday 27 August 2009 01:21:43 pm David Flatley wrote: > When auditd starts and reports an error on a line in the audit.rules, > does auditd continue to run with the rest of the rules? > Or does auditd stop waiting for a correction to the rules file? It depends on whether or not its processed a "-i" directive in the rules. If not, it stops. If so, it continues. -Steve From mboxrd@z Thu Jan 1 00:00:00 1970 From: LC Bruzenak Subject: Re: buffer space Date: Thu, 27 Aug 2009 12:33:23 -0500 Message-ID: <1251394403.20970.242.camel@homeserver> References: <1250532894.3048.729.camel@homeserver> <4A89A586.9020008@conceras.com> <200908171537.37593.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (ext-mx06.extmail.prod.ext.phx2.redhat.com [10.5.110.10]) by int-mx04.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n7RHXau0016695 for ; Thu, 27 Aug 2009 13:33:36 -0400 Received: from mail.magitekltd.com (rrcs-24-242-137-197.sw.biz.rr.com [24.242.137.197]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n7RHXOfN016678 for ; Thu, 27 Aug 2009 13:33:25 -0400 Received: from [24.242.137.194] (helo=[192.168.30.40]) by mail.magitekltd.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Mgioy-0001PK-Pj for linux-audit@redhat.com; Thu, 27 Aug 2009 12:31:36 -0500 In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Linux Audit List-Id: linux-audit@redhat.com On Thu, 2009-08-27 at 13:21 -0400, David Flatley wrote: > When auditd starts and reports an error on a line in the audit.rules, > does auditd continue to run with the rest of the rules? > Or does auditd stop waiting for a correction to the rules file? An > example would be on syscalls for fchown32 or umount. > Thanks. > > > David Flatley CISSP > David, You can always run "sudo auditctl -l" to see which ones are loaded. LCB. -- LC (Lenny) Bruzenak lenny@magitekltd.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Flatley Subject: Re: buffer space Date: Thu, 27 Aug 2009 13:45:06 -0400 Message-ID: References: <200908171537.37593.sgrubb@redhat.com> <200908271332.20237.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1687473384==" Return-path: In-Reply-To: <200908271332.20237.sgrubb@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com --===============1687473384== Content-type: multipart/related; Boundary="0__=0ABBFC8CDFF2F3728f9e8a93df938690918c0ABBFC8CDFF2F372" --0__=0ABBFC8CDFF2F3728f9e8a93df938690918c0ABBFC8CDFF2F372 Content-type: multipart/alternative; Boundary="1__=0ABBFC8CDFF2F3728f9e8a93df938690918c0ABBFC8CDFF2F372" --1__=0ABBFC8CDFF2F3728f9e8a93df938690918c0ABBFC8CDFF2F372 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Can you give me an example of the use of -i Thanks. David Flatley CISSP = From: Steve Grubb = = To: David Flatley/Burlington/IBM@IBMUS = = Cc: linux-audit@redhat.com = = Date: 08/27/2009 01:32 PM = = Subject: Re: buffer space = = On Thursday 27 August 2009 01:21:43 pm David Flatley wrote: > When auditd starts and reports an error on a line in the audit.rul= es, > does auditd continue to run with the rest of the rules? > Or does auditd stop waiting for a correction to the rules file? It depends on whether or not its processed a "-i" directive in the rule= s. If not, it stops. If so, it continues. -Steve = --1__=0ABBFC8CDFF2F3728f9e8a93df938690918c0ABBFC8CDFF2F372 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Can you give me an example of the use of -i
Thanks.

David Flatley CISSP

3D"InactiveSteve Grubb ---08= /27/2009 01:32:35 PM---On Thursday 27 August 2009 01:21:43 pm David Fla= tley wrote: > When auditd starts and reports an e

= =
3D=
From:
= 3D""
Steve Grubb <sgrubb@redhat.com>
3D=
To:

David Flatley/Burlington/IBM@IBMUS
3D=
Cc:
3D""
linux-audit@redhat.com
3D=
Date:
= 3D""
08/27/2009 01:32 PM
3D=
Subject:
3D""
Re: buffer space





On Thursday 27 August 2009 01:21:43 pm David Flatley wrote:
>    When auditd starts and reports an error on a line in = the audit.rules,
> does auditd continue to run with the rest of the rules?
> Or does auditd stop waiting for a correction to the rules file?
It depends on whether or not its processed a "-i" directive i= n the rules. If
not, it stops. If so, it continues.

-Steve


= --1__=0ABBFC8CDFF2F3728f9e8a93df938690918c0ABBFC8CDFF2F372-- --0__=0ABBFC8CDFF2F3728f9e8a93df938690918c0ABBFC8CDFF2F372 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABBFC8CDFF2F3728f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBFC8CDFF2F3728f9e8a93df938690918c0ABBFC8CDFF2F372 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <2__=0ABBFC8CDFF2F3728f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBFC8CDFF2F3728f9e8a93df938690918c0ABBFC8CDFF2F372-- --===============1687473384== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============1687473384==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: buffer space Date: Thu, 27 Aug 2009 14:45:41 -0400 Message-ID: <200908271445.41516.sgrubb@redhat.com> References: <200908271332.20237.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: David Flatley Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Thursday 27 August 2009 01:45:06 pm David Flatley wrote: > Can you give me an example of the use of -i ## First rule - delete all -D ## Increase the buffers to survive stress events. ## Make this bigger for busy systems -b 8192 ## Set failure mode to panic -f 2 ## Ignore any errors and keep loading -i ....