Re: Protecting contents of AUDIT_FILE_DEST from 'oracle' OS user on *NIX...

From: David Robillard <>
Date: Sat, 19 Nov 2011 11:48:03 -0500
Message-ID: <>

Hello David,

Why don't you send the audit logs over to syslog? Once configured to work with syslog, you can keep a local copy or have then sent over to your central syslog server. Easy, clean and secure.

Maybe that could help? </ShamelessPlug>

HTH, David

David Robillard

> I have been diving into auditing over the past few weeks and have
> worked out almost all the scenarios that we are interested in
> auditing. Most of the actions are related to user activity. We have
> one database where the customer wants all SYS activity audited as
> well. These are 10gR2 or later databases on Solaris and Linux.
> So I checked multiple blog posts, articles, and metalink docs and
> finally saw one that mentioned my concern... I was trying to figure
> out what can keep a SYS user from invoking say UTL_FILE and messing
> with a file that lives in AUDIT_FILE_DEST directory or just logging in
> as the oracle OS user and rm * in the AUDIT_FILE_DEST directory.
> From [ID 174340.1] "Audit SYS User Operations". : "The SYS audit
> records must go to OS files since the user SYS can delete his actions
> from AUD$, whereas if the files are written to the OS, they can be
> secured from the Oracle DBA by root (root must have some means to
> transfer the files to a secure location). It is not possible to
> configure that these records go into the AUD$ table."
> I can only think of one right now but it doesn't seem nearly secure
> enough. I guess I could have a sysadmin write a cron script to run as
> root and copy contents of the directory to a destination not
> acccessible by the oracle OS user. But what is the resolution of CRON?
> 1 minute? Of course would have to make sure we only copied the file
> once so if the source file was changed at a later date it could be
> detected.
> Can anyone suggest any other configurations or mechanisms can be set
> up to protect these files?
> Thanks,
> -Dave
Received on Sat Nov 19 2011 - 10:48:03 CST

Original text of this message