Re: Protecting contents of AUDIT_FILE_DEST from 'oracle' OS user on *NIX...
Date: Fri, 18 Nov 2011 16:49:34 +0000
Message-ID: <W34809198837061321634974_at_webmail51>
David,
In the past, I've decided that it isn't necessary to move the ".aud" files, but just to change their ownership. Much later on, they can be moved as needed to an archive location.
So, I created a UNIX shell script to be executed by "cron" as "root" to execute the UNIX "find" command to execute "chown root:sys" on any ".aud" files in the AUDIT_FILE_DEST directory which are presently owned by the Oracle software owner (i.e. "oracle").
So, here is a simplified sample script named "chown_adump.sh"...
#!/bin/ksh
#
sleep $1 # first, sleep specified number of seconds
#
_ADumpDir=${ORACLE_BASE}/admin/${ORACLE_SID}/adump # AUDIT_FILE_DEST directory pathname
_OracleOwner=oracle # name of Oracle software owner
#
find ${_ADumpDir} -name "*.aud" -owner ${_OracleOwner} -exec chown root:sys {} \;
Then, in the "crontab" for "root", specify entries such as this, in this example implementing a 15-second frequency...
- * * * * /scripts/root/chown_adump.sh 1
- * * * * /scripts/root/chown_adump.sh 16
- * * * * /scripts/root/chown_adump.sh 31
- * * * * /scripts/root/chown_adump.sh 46
All four entries will start every minute, but they will sleep for the specified period of time and then execute. Of course, this could be done within a single script with 4 sleeps, etc...
Hope this helps...
Tim Gorman
consultant => Evergreen Database Technologies, Inc.
postal => PO Box 352151, Westminster CO 80035
email => Tim_at_EvDBT.com
mobile => +1-303-885-4526
fax => +1-303-484-3608
Lost Data? => http://www.ora600.be/ for info about DUDE...
On 11/18/2011 7:41 AM, David Mann wrote:I have been diving into auditing over the past few weeks and haveworked out almost all the scenarios that we are interested inauditing. Most of the actions are related to user activity. We haveone database where the customer wants all SYS activity audited aswell. These are 10gR2 or later databases on Solaris and Linux.So I checked multiple blog posts, articles, and metalink docs andfinally saw one that mentioned my concern... I was trying to figureout what can keep a SYS user from invoking say UTL_FILE and messingwith a file that lives in AUDIT_FILE_DEST directory or just logging inas the oracle OS user and rm * in the AUDIT_FILE_DEST directory.>From [ID 174340.1] "Audit SYS User Operations". : "The SYS auditrecords must go to OS files since the user SYS can delete his actionsfrom AUD$, whereas if the files are written to the OS, they can besecured from the Oracle DBA by root (root must have some means totransfer the files to a secure l ocation). It is not possible toconfigure that these records go into the AUD$ table."I can only think of one right now but it doesn't seem nearly secureenough. I guess I could have a sysadmin write a cron script to run asroot and copy contents of the directory to a destination notacccessible 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 fileonce so if the source file was changed at a later date it could bedetected.Can anyone suggest any other configurations or mechanisms can be setup to protect these files?Thanks,-Dave
-- http://www.freelists.org/webpage/oracle-lReceived on Fri Nov 18 2011 - 10:49:34 CST