Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

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

Re: V$ tables

From: Pete Finnigan <pete_at_peterfinnigan.demon.co.uk>
Date: Fri, 12 Jul 2002 15:33:38 +0100
Message-ID: <x8sEcQACjuL9EwQ6@peterfinnigan.demon.co.uk>


In article <db479d88.0207120141.767c03c2_at_posting.google.com>, Charlie Edwards <Charlie3101_at_hotmail.com> writes
>Daniel Morgan <dmorgan_at_exesolutions.com> wrote in message news:<3D2E0CF2.453F041
>C_at_exesolutions.com>...
>> Pete Finnigan wrote:
>>
>> > In article <3D2DABC9.F38D4991_at_exesolutions.com>, Daniel Morgan
>> > <dmorgan_at_exesolutions.com> 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
>> > >>
>> > >> pete_at_peterfinnigan.demon.co.uk
>> > >> pete_at_petefinnigan.com
>> > >>
>> > >> http://www.pentest-limited.com/oracle-security.htm - "Exploiting and
>> > >> protecting Oracle"
>> > >>
>> > >> http://online.securityfocus.com/infocus/1522 - "A simple Oracle Security
>> > >> Scanner"
>> > >>
>> > >> http://www.pentest-limited.com/default-user.htm - "Oracle Default User
>> > >> and Password List"
>> > >>
>> > >> http://www.pentest-limited.com/utl_file.htm - "Extracting Clear Text
>> > >> Passwords from the SGA"
>> > >>
>
><snip>
>
>>
>> I too agree with restricting access and my rant that follows should be read
>with
>> that in mind. But I believe in restricting it as is appropriate to the tasks
>at
>> hand. Treating developers like end-users just moves the senior developers to
>quit
>> 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
>done
>> 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
>ALTER
>> 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
>myth
>> debunked here recently.
>>
>> And let me add that if the concern is that some developer will do something
>else
>> 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
>to
>> present at the unemployment office. If developers are not free to utilize all
>of
>> the tools Oracle provides to do their job the end result will be exactly the
>kind
>> 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

cheers

Pete
>CE

-- 
pete Finnigan

pete_at_peterfinnigan.demon.co.uk
pete_at_petefinnigan.com

http://www.pentest-limited.com/oracle-security.htm - "Exploiting and
protecting Oracle"

http://online.securityfocus.com/infocus/1522 - "A simple Oracle Security
Scanner"

http://www.pentest-limited.com/default-user.htm - "Oracle Default User
and Password List"

http://www.pentest-limited.com/utl_file.htm - "Extracting Clear Text
Passwords from the SGA"
Received on Fri Jul 12 2002 - 09:33:38 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US