Re: OK to revoke privileges from SYS or DBA?

DA Morgan wrote:
> > can you provide a link as to where oracle advise dropping the dba
role >
>
> I've been asked this question before and tried to track down the
> reference unsuccessfully. This time, perhaps due to having some
> sleep over the weekend I was successful.
>
>

http://asktom.oracle.com/pls/ask/f?p=4950:8:9772908208972569857::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:7540675724395,
>
> And it is a very long URL so make sure it doesn't break up.

www.tinyurl.com

> You will note the statement from the OP:
> I read your book and a article and read this quote where you have
quoted
> that "connect,resource and DBA should not be used in a system for
> security reasons".
>
> If it is good enough for Tom Kyte ... it is good enough for me to
> reference. ;-)

Well possibly. Tom doesn't advocate *dropping* any of the roles - he advocates not *using* them, on my reading anyway. This is not quite the same thing. In particular various bits and pieces that Oracle themselves install create users using one or more of these roles (they shouldn't but they do). Now if you are attempting to be secure you wouldn't install bits and pieces of the supplied Oracle functionality unless you were currently using them. So say, for example, that someone comes along and decides that full text search would be a nice added value feature for your database driven website. Fortunately Oracle provides a rather nice set of functionality for this free of charge with the database. Unfortunately dropping connect and resource will rather screw up the installation of this functionality.

I'd much rather REVOKE the privileges from users after the database installation is complete.

> I am a firm believe in dropping all three roles and creating new
roles,
> perhaps with the same names though I prefer not, that meet
specifically
> defined and documented requirements for employee activities. If you
can
> not document a need for a privilege it should not be granted. It may
be
> that no harm comes from it ... but no good can come of it either. So
> better to err on the side of security.

creating roles that have the same name as a well-known role but with a different set of privileges is a sure-fire route to support hell.

> And I'll go one step further while we are discussing security. Once a
> production schema is built ... the CREATE and ALTER privileges such
as
> CREATE PROCEDURE and ALTER TABLE should be dropped.

I agree - of course this assumes that you have written apps that don't need these privs in normal day to day operation :(. Niall Litchfield
Oracle DBA
http://www.niall.litchfield.dial.pipex.com Received on Mon Dec 06 2004 - 07:19:02 CST