| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: V$ tables
Charlie Edwards wrote:
> 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"
> > > >>
>
>> >
> >
> > 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>
>
>
>
I agree with your point about someone doing bad things with ALTER SYSTEM. I once saw a angry employee take a tube of crazy glue and glue the ON-OFF switch permanently on, the connectors from mouse and keyboard permanently to the machine, etc. And after five minutes of confusion, and ten minutes of anger, we got a good laugh ... and still do. You wouldn't advocate strip searches for tubes of crazy glue would you? ;-)
But by the same token an angry DBA or angry SYSADMIN could do even more damage. So what is the issue here? That professional developers are more likely to be provoked into acts of career limiting stupidity than those with other IT skills? If it is a development database, and that is what we are discussing here, there are no transactions to lose. The source code is backed up in some independent tool and on tape. So you have to rebuild it once every two years because of some adolescent idiocy. Is that worth all of the problems that come from neutering developers? I think not.
Daniel Morgan
(all of the above written with a light heart and a smile)
Received on Fri Jul 12 2002 - 10:27:03 CDT
 |
 |