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

  • From: Don Granaman <DonGranaman@xxxxxxxxxxxxxxx>
  • To: "dmann99@xxxxxxxxx" <dmann99@xxxxxxxxx>, "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
  • Date: Fri, 18 Nov 2011 11:23:17 -0600

You *can* make audit_dump_dest a directory owned by the "oracle" user, but with 
group "auditors" (or something other than dba), and then use the "oracle" OS 
account for routine DBA stuff.  With this, members of the dba group cannot 
tinker with audit_dump_dest.

The basic idea is to prohibit OS logins as oracle unless an exception has been 
granted - and use "sudo -u oracle ..." for other purposes, which logs the 
activity in the sudoers log.

Another potential option would be to set syslog_level and append the audit 
records to syslog.  This one has a bunch of thorns though...

Don Granaman | Phone: 402-361-3073 | Cell: 402-960-6955 | Fax: 402-361-3173 | 
Solutionary | Relevant . Intelligent . Security

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On 
Behalf Of David Mann
Sent: Friday, November 18, 2011 8:41 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: Protecting contents of AUDIT_FILE_DEST from 'oracle' OS user on *NIX...

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

-- 
Dave Mann
www.brainio.us
www.ba6.us - Database Stuff - http://www.ba6.us/rss.xml
--
//www.freelists.org/webpage/oracle-l


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


Other related posts: