Pete Finnigan's Oracle Security Weblog

I saw a nice post today by Chen Shapira via my Oracle blogs aggregator. The post by Chen is called "Psychology of Instrumentation" and whilst it is not a security post; this is an area I cover in my training class on "how to perform a security audit of an Oracle database". I want in my class to emphasise the non-flat world model of accessing data - in other words if your credit cards are stored in a table called CREDIT_CARD do not be simplistic in thinking the only way to read the credit cards is to perform a select statement against the CREDIT_CARD table. It is almost certainly not the only way.

So, I have to add something negative to Chens article - that just goes with the role of being a security person, being negative that is..:-).

Instrumentation is great, I have written in C, PL/SQL, Perl and many more languages over the years and the usual first peice of code i write is some sort of debug/trace/instrumentation interface so i like instrumentation - BUT - in the case of Oracle we do already have a huge amount of instrumentation, traces, data dumps, file dumps, redo dumps, header dumps, sql*net trace, logs, events, statspack, AWR, ASH.... This list simply goes on....

The downside is whilst this stuff is great for understanding how the system works and why it maybe slow often all of these methods of tracing or instrumenting can undo the good security work done. Imagine a case where we protect and harden access to our CREDIT_CARD table. We ensure only authorised users can select from the table; great we are secure. Imagine that most users have the ALTER SESSION system privilege and therefore they can dump data to trace files by running a trace on a process or program that they have access to run but perhaps can only see a very limited set of data via a screen (of course they would need to be able to read the trace file; in my experience this is often not a problem due to file system access, exposure of trace files through the applications (E-Business Suite is a good example), often DBA's may email trace files to people; imagine that we have secured some data in the table using VPD; this same method (trace) allows bypass of VPD by virtue of certain events allowing the dumping of predicates so that the "rules" applied can be determined, maybe the predicate function can be executed.... Imagine we allow users to set trace and the code does not use binds or it does use binds and setting extended trace is possible, again data can be read perhaps that should not be.

Whilst instrumentation is great we should be cautious and even suspicious and not let these mechansisms be used to get at the data.

[Thanks to Christopher Newman's email and Alex's comments for picking up my lax typing and editing issues - i have editied the post to say what I meant originally]