Re: V$ tables

Daniel Morgan <dmorgan_at_exesolutions.com> wrote in message news:<3D2E0CF2.453F041C_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

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!

CE Received on Fri Jul 12 2002 - 04:41:19 CDT