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

Maybe i am missing something and i am not able to test for myself where i am today but if you change the owner of any file to root:sys what happens when the same file is needed to be appended to? - oracle uses the PID on the file name and appends when the file exists?

cheers

Pete

Tim Gorman wrote:
> 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 secur
e 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-l
>
>
>

-- 

Pete Finnigan
CEO and Founder
PeteFinnigan.com Limited

Specialists in database security.

Makers of PFCLScan the database security auditing tool.
Makers of PFCLObfuscate the tool to protect IPR in your PL/SQL

If you need help to audit or secure an Oracle database, please ask for
details of our training courses and consulting services

Phone: +44 (0)1904 791188
Fax  : +44 (0)1904 791188
Mob  : +44 (0)7759 277220
email: pete_at_petefinnigan.com
site : http://www.petefinnigan.com

Registered Office: 9 Beech Grove, Acomb, York, YO26 5LD, United Kingdom
Company No       : 4664901
VAT No.          : 940668114

Please note that this email communication is intended only for the
addressee and may contain confidential or privileged information. The
contents of this email may be circulated internally within your
organisation only and may not be communicated to third parties without
the prior written permission of PeteFinnigan.com Limited.  This email is
not intended nor should it be taken to create any legal relations,
contractual or otherwise.

--
http://www.freelists.org/webpage/oracle-l