Too many failed open syscalls

[Steve Grubb]

On Wednesday, February 09, 2011 12:09:50 pm Steve M. Zak wrote:
> We have been having an issue that got much worse just recently where the
> audits based on nispom.rules are generating millions of failed "open"
> syscall events.

The file in the audit package should probably have some customizations in it.

> In the past I saw failed open for the lock files under
> /usr/lib64/qt-3.3/etc/settings/... This seems to be related to KDE and
> maybe Kdevelop.  The number of events were manageable.
> 
> gdb is now asking for many files under /usr/local/gcc441/...  and under a
> home directory where gcc was configured where users have read permissions.
>  Does this seem like an audit issue or a gcc/gdb issue?  I can filter the
> audit.log, but 1GB of audit logs a day is too much.

Paragraph 8-602a(1)(c) is this:
c) Successful and unsuccessful accesses to security-relevant objects and directories, 
including creation, open, close, modification, and deletion.

In Industrial Security Letter ISL 01L-1 question 55, this was clarified as:
Only unsuccessful accesses need to be audited. 

Then in Industrial Security Letter ISL 2007-01, more was said:
All OS contain SRO and directories but the location (folder or directory) and the OS
configuration may vary with the OS. The following table represents a standard 
configuration of SRO to be audited for Windows NT and UNIX. Please note that while the 
SRO and directories will remain constant, directory examples can vary by installation, 
by administrator and by OS. 

They go on with a table which essentially means you need to audit almost everything. 
But you only need to worry about the failed access. You might check your audit rules 
to see what you are auditing for the open syscall.

-Steve