Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> c.d.o.server -> Re: V$ tables

Re: V$ tables

From: Pete Finnigan <>
Date: Fri, 12 Jul 2002 15:33:38 +0100
Message-ID: <>

In article <>, Charlie Edwards <> writes
>Daniel Morgan <> wrote in message news:<3D2E0CF2.453F041
>> Pete Finnigan wrote:
>> > In article <>, Daniel Morgan
>> > <> writes
>> > >Pete Finnigan wrote:
>> > >
>> > >> Hi All
>> > >>
>> > >> I know this reply is a month late but I wanted to add to this thread as
>> > >> its relevant for me. Someone in the thread suggested its OK to grant
>> > >> access to all v$ and dba_ views?.
>> > >>
>> > >> I am currently writing a step-by-step guide for securing Oracle for the
>> > >> SANS institute and I am interested in the groups view "on security
>> > >> grounds" of which "dba_", "v$" or "all_" views should have access
>> > >> granted to them. Obviously developers and others sometimes need access
>> > >> to some of these views for tuning, system info etc - but exactly which
>> > >> ones? and why are they safe?
>> > >>
>> > >> In my view, for security we should always use the "least privilege"
>> > >> principle and remove all default privileges and grant back what is
>> > >> actually needed. Most databases I have seen are not very secure and
>> > >> usually development databases are worse. Most unauthorised access is
>> > >> employees disgruntled or otherwise looking at what they should not.
>> > >>
>> > >> For instance I would not allow access either directly or through roles
>> > >> to DBA_USERS. Access to that reveals the password hashes ( although
>> > >> there are a number of other ways to get at them), the "values" command
>> > >> can only be used as a DBA so what use are they to anyone?, well its
>> > >> possible to use the hash. A brute force attack of the password can be
>> > >> done off line for instance when the hash is known. Even access to
>> > >> all_users might seem innocuous but it gives the reader of the view a
>> > >> complete list of users and then a simple SQL statement can generate a
>> > >> set of connect attempts for all users. There are many more examples I
>> > >> can think of.
>> > >>
>> > >> Anyway I am interested in everyone's view of which views are "really"
>> > >> not a risk. to be granted to developers.
>> > >>
>> > >> cheers
>> > >>
>> > >> pete Finnigan
>> > >>
>> > >>
>> > >>
>> > >>
>> > >> - "Exploiting and
>> > >> protecting Oracle"
>> > >>
>> > >> - "A simple Oracle Security
>> > >> Scanner"
>> > >>
>> > >> - "Oracle Default User
>> > >> and Password List"
>> > >>
>> > >> - "Extracting Clear Text
>> > >> Passwords from the SGA"
>> > >>
>> I too agree with restricting access and my rant that follows should be read
>> that in mind. But I believe in restricting it as is appropriate to the tasks
>> hand. Treating developers like end-users just moves the senior developers to
>> and go somewhere where they will be appreciated for their skills and can get a
>> decent job done.
>> Actually killing a session does not require ALTER SYSTEM. It can be done with
>> kill -9 in UNIX and can be done with ORAKILL. But even if it could only be
>> with ALTER SYSTEM there is nothing that stops someone from creating a stored
>> procedure that does the dirty work where the developer only has execute on the
>> procedure and can only kill their own sessions. This is like five minutes of
>> coding at most.
>> <RANT>
>> But I would like any DBA out there that has ever had a bad experience with
>> SYSTEM, in a development enviornment, to step forward. I've yet to meet one. I
>> think this is paranoia with the same level of validity as many other Oracle
>> debunked here recently.
>> And let me add that if the concern is that some developer will do something
>> with ALTER SYSTEM other than kill their own sessions ... then perhaps that
>> developer should be escorted to the door and handed a letter of recommendation
>> present at the unemployment office. If developers are not free to utilize all
>> the tools Oracle provides to do their job the end result will be exactly the
>> of garbage I see in such abundance.
>> I suggest a poll be conducted here of DBAs managing development databases.
>> Q1: Have you given access to DBMS_PROFILER to your developers?
>> Q2: If not, why not?
>> Q3: If not how do you expect to receive decent code from developers?
>> Q4: If not, and without going to a book, or web site, and looking it up do you
>> know what DBMS_PROFILER is?
>> The prosecution rests.
>> </RANT>
>> Daniel Morgan

Hi Charlie

I think we have done this to death now.

I am not wanting to restrict things just for the hell of it, I am writing a step-by-step guide to secure Oracle for the SANS institute and this thread was relevant to me. I am looking to quote the minimum access rights for V$, DBA and ALL% views that potentially would have no security issues for anyone.

As i said before its just least privilege principle. What is the least the need to be able to work and learn without causing security risks.  

>As a developer, I agree with Daniel. I would say, however, that I
>wouldn't expect ALTER SYSTEM to be granted to developers to guard
>against the scenario where a disgruntled employee was already about to
>leave and wanted to be malicious.
>Why would a DBA possibly want to restrict access to to V$ views? Let
>me see, it might help then learn more about Oracle. So they might be
>more likely to become DBAs themselves, and do the DBA out of a job.
>Ah, it all makes sense now!
>I suppose if you're a DBA specialising in Security, it's not a bad
>thing to be so paranoid. But how depressing!

I have seen quite a lot of oracle databases that are not secure and believe me paranoia doesn't come into it. It is in most cases a lack of common sense and care. For the guide I am trying to cover every angle possible to make it complete. This guide is aimed not just at development but at all types of companies and installations up to military/government.

Thanks for the comments though



pete Finnigan - "Exploiting and
protecting Oracle" - "A simple Oracle Security
Scanner" - "Oracle Default User
and Password List" - "Extracting Clear Text
Passwords from the SGA"
Received on Fri Jul 12 2002 - 09:33:38 CDT

Original text of this message