On Tuesday 10 January 2006 12:44, Lisa Giacchetti wrote: >I have a redhat enterprise linux 4 update 1 based system running >2.6.13-2smp kernel with audit-1.0.3-6.EL4 and audit-libs-1.0.3-6.EL4 >installed. That kernel does not sound like a RHEL4 kernel. The RHEL4 kernel carries all the patches that the kernel needs for the audit system to work. >The problem is that when I start auditd I get this error: > >[root@cmsstor02 etc]# /etc/init.d/auditd start >Starting auditd: [ OK ] >Error receiving watch list (Invalid argument) >There was an error in line 5 of /etc/audit.rules Non-RHEL4 kernels do not have the right patch for file system auditing. When it was sent upstream, there was some consolidation with inotify suggested before acceptance. That work is still in progress. So...no kernel except the RHEL4 kernel really has the file system auditing at this point. >auditd actually starts but I am concerned that the -D >option (which is what is on line 5 of /etc/audit.rules) >is not being recognized or honored. If you do not need file system auditing, then you can safely ignore this. If you do need it, you need to change kernels. >I see that newer versions of the audit rpm may have fixed this That one is older. >"* Thu May 26 2005 Steve Grubb <sgrubb(a)redhat.com&gt; 0.9-1 > - Translate numeric info to human readable for ausearch output > - add '-if' option to ausearch to select input file > - add '-c' option to ausearch to allow searching by comm field > - init script now deletes all rules when daemon stops > - Make auditctl display perms correctly in watch listings >*** - Make auditctl -D remove all watches" > >but I do not have the glibc-kernheaders needed. Mine >are glibc-kernheaders-2.4-9.1.87 and audit-1.0.1201 needs >glibc-kernheaders>=2.4-9.1.95. We ship all the right pieces so that RHEL4 stuff is coordinated with itself and FC4 is coordinated with itself. 1.0.12 will be released with U3 update, but it will not solve the problem you are reporting. -Steve

On Tuesday 10 January 2006 13:48, Lisa Giacchetti wrote: > Technically I do not need file system auditing. My primary goal is >to get rid of the thouands of messages in /var/log/messages of the >type: The patches that we sent upstream did not go in a terribly organized way. There was a patch specifically to stop user space originating audit messages when the audit system was disabled. I think you may need 2.6.14 to have that patch. In any event, the audit daemon enables auditing on startup. So, just doing "chkconfig --levels auditd 2345 off" should do it. The RHEL4 audit package shipped with the audit daemon disabled, so it got enabled somehow.

>The system is based on RHEL4. It comes with audit-0.5-1 and >audit-libs-1.0.3-6.EL4 installed. 0.5 was an empty package. >I have found that upgrading to the newer version, audit-1.0.3-6.EL4, >moves the audit messages above to /var/log/audit/audit.log. >Even with the error at start, this is accomplished. Using 1.0.3 might be the best solution if you have a kernel without the patch to stop user space originating messages. Just set the log size low and tell it to suspend logging when the file gets too big. flush = INCREMENTAL freq = 50 num_logs = 2 max_log_file = 1 max_log_file_action = SUSPEND

-Steve

On Tuesday 10 January 2006 14:31, Lisa Giacchetti wrote: >So I installed 1.0.3-6 which did have auditd chkconfig'd off by default. >Add I rebooted. It did not work. Well I should say that auditd is not >running but the messages are still there. OK, your kernel does not have the patch, then. There's 3 options. You can try for a newer kernel, or patch the one you are using, or use auditd to eat up the messages but live with the error on boot. You will pay a performance penalty for enabling the audit system. I can dig up the kernel patch if you want to patch your kernel.

>>Using 1.0.3 might be the best solution if you have a kernel without the >>patch to stop user space originating messages. Just set the log size low >>and tell it to suspend logging when the file gets too big. >> >>flush = INCREMENTAL >>freq = 50 >>num_logs = 2 >>max_log_file = 1 >>max_log_file_action = SUSPEND > >Won't I still have the problem of the error on start up? Yes, but its harmless - your kernel doesn't support file system auditing. >Its like the -D option on line 5 is not a recognized option. It is recognized, the error message is somewhat misleading (I think it was updated in later versions). It is saying that it tried to get the list of files being watched and the kernel didn't understand.

>I really don't care about the error as long as I know that >things are configured to not really start auditing. Well, auditing comes in 2 layers. If auditing is enabled, all the syscalls will pass through the audit system system for inspection. There is a performance penalty for this. The other layer is when you have rules loaded that may trigger events. This will result in kernel audit messages.

-Steve

On Tuesday 10 January 2006 15:17, Lisa Giacchetti wrote: >Steve Grubb wrote: > >>performance penalty for enabling the audit system. I can dig up the >>kernel patch if you want to patch your kernel. > >Yes I think this would be good. At some point we may want/need to have >auditing on so having it installed correctly is a good path to follow. You can find the patch here: https://www.redhat.com/archives/linux-audit/2005-June/msg00077.html A quick check of 2.6.14 shows that its patched there. -Steve