Re: Auditing DBAs

From: Ana C. Dent <anacedent_at_hotmail.com>
Date: Sun, 17 Oct 2004 01:35:32 GMT
Message-ID: <Xns9584BD21BCFB3SunnySD@68.6.19.6>

"Howard J. Rogers" <hjr_at_dizwell.com> wrote in news:4171c327$0$20129$afc38c87_at_news.optusnet.com.au:

> Mark D Powell wrote:
> 
>> Daniel Morgan <damorgan_at_x.washington.edu> wrote in message
>> news:<1097949538.946698_at_yasure>...

>>> Howard J. Rogers wrote:
>>>
>>> > I presumably missed the bit where everyone posted the fact that in
>>> > 9i Release 2, auditing SYS operations is a piece of cake, and
>>> > requires the setting of one init.ora/spfile parameter.
>>>
>>> I did.
>>>
>>> > Audit_sys_operations=true is your friend.
>>> >
>>> > It requires that you set the directory where the SYS audit trail
>>> > is written to, and that requires in turn that you set appropriate
>>> > O/S permissions on that directory so that Mr. DBA doesn't just
>>> > waltz in to the directory and delete the audit trail. But nothing
>>> > a moderately competent Unix administrator couldn't cope with, I
>>> > suspect.
>>> >
>>> > Regards
>>> > HJR

>> 
>> And since the DBA has access to the OS Oracle Id, which naturally has
>> full OS permissions to the audit trail directory, cleaning up the
>> audit trail should be a snap. 8-D
> 
> I bow to superior Unix knowledge wherever I can get it, but it should
> not be beyond the wit of a system administrator to devise a directory
> with permissions that let an Oracle instance write to the directory,
> but not permit an Oracle user, however well qualified as a DBA, to
> delete it. 

I was a *nix SA for about 8 years before switching to DBA duties. I contend that write=delete, but should you not accept this, then consider

Assuming I have 'write' access ( but not "delete" access), I just $ cp /dev/null /pathname/audit.log While the file may not have been deleted, it certainly does not contain useful information.

While thinking about this & similar challenges (such as how do you "audit" root) access on any *nix system, the best I could come up with is a custom sshd (that runs as root) that records every keystroke to an "obscure" file. Yes, anyone running as root could replace the custom sshd, but if they did not know it existed, I doubt that it would be detected. This could be considered by some a security via obscurity, but it is VERY difficult to verify that $DIETY on a system or in an application always does the "RIGHT" thing. Received on Sat Oct 16 2004 - 20:35:32 CDT