Re: Auditing DBAs

From: Howard J. Rogers <hjr_at_dizwell.com>
Date: Sun, 17 Oct 2004 13:45:37 +1000
Message-Id: <4171eae1$0$4310$afc38c87@news.optusnet.com.au>

Ana C. Dent wrote:

> "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.

Clearly, I am not making myself very well understood.

The Oracle DBA should have ZERO access to the audit file destination. It is the Oracle *instance* that needs write access to it.

And that is a completely different, and easily implemented, matter.

Why I am having such a hard time explaining this, I can't think. Either I'm just phrasing things really badly; or I've got completely the wrong end of the stick; or you (and many other people, apparently) frequently let your DBA users log on as themselves to perform Oracle installations -so that the concept of Oracle being owned and running with the privileges of (say) the O/S user "oracle", whilst the DBA logs on as someone called "Fred" or "Irene" to perform database administration functions, is entirely alien to you (and them).

But if you perform that split of functionality and privileges, then neither Fred nor Irene as O/S users will have rights to the directories that the Oracle instance reads and writes to. Neither DBA will therefore be able to wipe, swipe or over-write the audit trail records being produced by the instance.

Regards
HJR
> 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 - 22:45:37 CDT