Too many failed open syscalls

Too many failed open syscalls

[Steve M. Zak]

[-- Attachment #1.1: Type: text/plain, Size: 873 bytes --]

Hi,

audit-2.0.6 sounds interesting.

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.

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.

Any help would be appreciated!

Thanks!


____________________________________________
Steve M. Zak





-- 
This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com

[-- Attachment #1.2: Type: text/html, Size: 1575 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: 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

Re: Too many failed open syscalls

[Steve Grubb]

On Wednesday, February 09, 2011 05:05:52 pm Todd Heberlein wrote:
> On Feb 9, 2011, at 10:17 AM, Steve Grubb wrote:
> > 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.
> 
> Translation: You only need to worry about failed attack. Ignore the
> successful attacks.

There are certain system objects where you have to audit both success and failure, 
e.g. /etc/shadow. However, if a file's permissions are 0644, do you really need to 
audit that the file was accessed, e.g. /etc/localtime?

-Steve