Bug 170472

By default, on a clean installation, auditing is not enabled in RHEL-3-U5+ 
( the 'audit' SysVinit service is not enabled in any runlevel by default ).

You should only enable auditing if you actually require the audit log records.

If you enable auditing, you need to configure a mechanism for handling 
audit log rotation and the case when there is insufficient disk space
to rotate an audit log - there are several mechanisms for doing so, as
documented in /etc/audit/audit.conf:

notify		= "/usr/sbin/audbin -S /var/log/audit.d/save.%u -C -T 20%";
#  AUDBIN THRESHOLDS:
#       The above notify will cause auditd to enter 'suspend' mode when 
#       free space on the /var/ filesystem falls below 20%. 
#       To take remedial action, eg. moving the oldest save file to /backup, use:
#	notify		= "/usr/sbin/audbin -S /var/log/audit.d/save.%u -C -T 20% -N 'mv -f %f
/backup'";
#       or even
#	notify		= "/usr/sbin/audbin -S /var/log/audit.d/save.%u -C -T 20% -N 'rm -f %f'";
#       This will free space by removing the oldest "save." files first from /var,
#       returning 0 to auditd and allowing it to continue.


See 'man audbin' for details on the -T and -N options.

By default, audit will put the system into suspend mode when insufficient 
disk space exists to save an audit log and maintain the audbin -T threshold.
This must be the default action to take, as any other action could result
in loss of audit data. 

You can either delete saved audit logs, move them to a different filesystem,
or not create 'save.*' saved audit log files at all, by making the audit.conf
notify option something like:
   notify =  "my_audit_log_analyser";
where "my_audit_log_analyser" is a script that uses the data in the binary 
audit log given its first argument, perhaps saving audit records of interest
to some database, and then calls 'audbin -C $audit_log' .

Many other users may depend on the filter.conf shipped by default in the laus
package, and the default filters cannot be changed to accomodate the needs of
Informix users.

Everything about the LAuS audit package is meant to be configured to suit 
individual user requirements, as you have done. 

No other RHEL-3 software depends on the audit system being enabled, so if do
not actually require the audit log data, the best solution is to disable
the audit service:
  # chkconfig --level=0123456 audit off
which is the state in which LAuS is installed on a clean install of RHEL-3-U5+. 

I, personally, can't think of any valid reason for any admin to depend on the
logging of semop() calls.  It's just noise and apparently not required by CAPP.

Nor can I think of any valid reason for a user to depend on a direct lift of the
*EXAMPLE* filter.conf from a white paper.  It would be much better to simply
expend the effort to create an useful filter.conf and restrict it to logging
what's required by CAPP and then letting the security admin add to it if their
needs require it.

Finally, I didn't install RHEL3 at Update 5, I installed it much earlier when
audit WAS enabled by default.  There are probably lots of RHEL3 systems
installed with audit enabled and in it's default configuration that are
vulnerable to a DOS attack by a user with a program calling semop() in an
infinite loop.  But if Red Hat would rather expend the effort to rationalize
this than to fix it and issue an errata, that's it's business I, suppose.  *sigh*

OK, I will remove the semop* filters from the default configuration. 
But this will not be fixed during upgrade, as /etc/audit/filter.conf is a 
%config(noreplace) file - users are expected to customize it to suit their
requirements, and an RPM upgrade will not replace this file - it will be
created as /etc/audit/filter.conf.rpmnew . I've committed this change to CVS
and it will be in laus-0.1-74RHEL3+ .  Also, we cannot disable the laus service
in an RPM upgrade - this must be left to the local administrator's decision, as
there is no way of determining if it was enabled only because it was installed
pre-RHEL-3-U5 or if the administrator enabled it after clean installing U5.
  

Hmmm, since RHBA-2005:219-07 neglected to mention that audit was previously
installed enabled by default and should be disabled until it's properly
configured, perhaps the new errata should include all these caveats and warnings
for sys admins who have never heard of CAPP or EAL3.

Wow... you've completely missed getting laus-0.1-74RHEL3+ into Update 6 or
Update 7!  I keep getting email, as recently as today, that you're making other
bugs depend on this one, but no errata activity for RHEL3 whatsoever on this
one.  Is Red Hat foot dragging until April 30, 2006?  Paying customers want to know.