Re: OK to revoke privileges from SYS or DBA?

Niall Litchfield wrote:
> 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.

Let me dis-ambiguate this totally

1. DO NOT DROP DBA.
2. don't use it if you don't have to.

period. that is what the above links states. do not drop anything like that, that would be "a bad thing (tm)". there will be times when DBA is in fact needed (DBA is 'special', the very name is 'special' in the code)

do not drop it

> 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.

do not drop connect, resource, dba - just DON'T USE THEM. As Niall said "big difference"

do not drop them, it is the sure road to %@@!$

>
> 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 - 10:13:22 CST