OK to revoke privileges from SYS or DBA?
Tom
one of the recommendations from an analysis tool is to remove some
privileges from SYS or DBA, namely privileges granted with the ADMIN
option.
Is it safe to change any of the privileges associated with the SYS
user or DBA role? Is this supported by Oracle?
Thanks,
Tom
Gerry Sinkiewicz
"Tom" <tdwil...@yahoo.com> wrote in message
news:ae755ef4.04120...@posting.google.com...
Send analysis tool back to wherever it came, it is bad software.
The recommendation is ill advised, but you do need to change the password
for SYS as quickly
after install as you can and make it strong.
I wish the writers of the tool would agree to be accountable for whatever
damage was consequential :-).
However, I guess it is the DBA's job to reject the recommendation as stupid,
idiotic, and incompetent.
The software is defective to say the least.
Michel Cadot
"Tom" <tdwil...@yahoo.com> a écrit dans le message de
news:ae755ef4.04120...@posting.google.com...
You can't revoke any privileges from SYS: he has all the privileges
and roles with admin/grant option.
You can drop DBA role and create your own one instead of revoking
some privileges from DBA to avoid misunderstandings.
Regards
Michel Cadot
DA Morgan
I'd drop the DBA role completely as that is what Oracle advises. It
exists, like CONNECT and RESOURCE solely for demonstration purposes
just as does SCOTT/TIGER.
Dropping privs from SYS, if it is possible, is preposterous on its
face as anyone logged on as SYS could always grant them again at will.
If you want fool-proof security this is not the way to achieve it.
You can contact me off-line if you wish and are a U.S. person.
--
Daniel A. Morgan
University of Washington
damo...@x.washington.edu
(replace 'x' with 'u' to respond)
Michel Cadot
"DA Morgan" <damo...@x.washington.edu> a écrit dans le message de news:1102272986.366416@yasure...
> You can contact me off-line if you wish and are a U.S. person.
Could I ask you why he must be a US person and why you don't post your solution here?
Regards
Michel Cadot
Dave
"DA Morgan" <damo...@x.washington.edu> wrote in message
news:1102272986.366416@yasure...
can you provide a link as to where oracle advise dropping the dba role
DA Morgan
You do recall I consult with a very large aerospace firm (aka a US
defense contractor). Some of the information I have is privileged and
can only be shared with US persons at specific firms or government
agencies.
That is why I asked to be contacted off-line by the OP.
DA Morgan
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.
And it is a very long URL so make sure it doesn't break up.
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. ;-)
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.
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.
Niall Litchfield
> > 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.
> 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
thoma...@oracle.com
> 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
a) DO NOT DROP DBA.
b) 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
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 %@@!$
DA Morgan
>>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.
I agree. But I have read elsewhere specific advice to drop them as they
are a security risk just by existing. Alternatively one can keep the
roles but drop those privs from them that are inappropriate.
I disagree that dropping CONNECT and RESOURCE will screw up any
aspect of Oracle. But if you insist certainly one could edit those
default roles to remove inappropriate privileges. What end-user,
for example, needs the ability to create clusters and database links?
And what DBA would want them to if they even knew what they were?
DA Morgan
Thanks for the clarification.
I'll change by advice to don't assign it to any user but rather
create your own internal role.
Thanks again.
Niall Litchfield
news:1102349602.1...@f14g2000cwb.googlegroups.com...
> Let me dis-ambiguate this totally
dis-ambiguate???
Niall
hpuxrac
snip
> I'd drop the DBA role completely as that is what Oracle advises. It
> exists, like CONNECT and RESOURCE solely for demonstration purposes
> just as does SCOTT/TIGER.
I disagree. Securing access to oracle provided roles is one thing,
recommending dropping the roles is another thing altogether.
I for one have never heard anyone from oracle advising the DBA role
should be dropped. I don't think that I would consider dropping
connect or resource role either.
Where does this recommendation come from exactly?
Is this something someone has done on a production system and why?
What were the ramifications?
This advice seems to me to be somewhat seat of the pants and highly
questionable. Willing to have it proven otherwise of course.
John
Anurag Varma
"DA Morgan" <damo...@x.washington.edu> wrote in message news:1102349725.487447@yasure...
connect, resource roles are used by oracle scripts themselves. Dropping them will not be good. I'm not sure why
you are still sticking to your advice of dropping them:
Try this in the rdbms/admin dir:
egrep -i 'grant ' *.* | egrep -i ' (connect|resource)( |,)'
a0801070.sql: execute immediate 'GRANT DEBUG CONNECT SESSION TO JAVADEBUGPRIV';
c0703040.sql: 'grant connect, resource, execute any procedure to outln',
c0800050.sql: 'grant connect, resource, execute any procedure to outln',
catqm.sql:grant resource to xdb;
catsnmp.sql:grant connect to OEM_MONITOR;
catsnmp.sql:grant resource to OEM_MONITOR;
catsnmp.sql:grant CONNECT, SELECT ANY DICTIONARY to DBSNMP;
catxdbr.sql:Rem nagarwal 11/05/01 - grant DML privileges to resource view
csminst.sql:grant connect, resource, dba to csmig
dbmslsby.sql:Rem jnesheiw 07/23/02 - grant connect, resource to logstdby_administrator
dbmslsby.sql:GRANT CONNECT, RESOURCE TO logstdby_administrator;
jvmsec5.sql:GRANT DEBUG CONNECT SESSION TO JAVADEBUGPRIV;
migrate.bsq:grant connect, resource, dba to migrate identified by migrate;
owmctab.plb:grant connect, resource, create public synonym, drop public synonym, create role to wmsys;
owmu901.plb:grant connect, resource, create public synonym, drop public synonym to wmsys;
prvtbiau.plb:1 GRANT CONNECT THROUGH :
sql.bsq:grant connect to outln
sql.bsq:grant resource to outln
utlsampl.sql:GRANT CONNECT,RESOURCE,UNLIMITED TABLESPACE TO SCOTT IDENTIFIED BY TIGER;
Anurag
Howard J. Rogers
> DA Morgan wrote:
>
> snip
>
>
>>I'd drop the DBA role completely as that is what Oracle advises. It
>>exists, like CONNECT and RESOURCE solely for demonstration purposes
>>just as does SCOTT/TIGER.
>
>
> I disagree. Securing access to oracle provided roles is one thing,
> recommending dropping the roles is another thing altogether.
>
> I for one have never heard anyone from oracle advising the DBA role
> should be dropped. I don't think that I would consider dropping
> connect or resource role either.
>
> Where does this recommendation come from exactly?
>
> Is this something someone has done on a production system and why?
> What were the ramifications?
>
> This advice seems to me to be somewhat seat of the pants and highly
> questionable. Willing to have it proven otherwise of course.
>
> John
>
It actually doesn't say to drop them anywhere in the Oracle
documentation as far as I can tell. It says they're there for backwards
compatibility reasons... which rather implies they have a use and a
function, and should therefore be left alone.
I notice their 9i Fundamentals II course notes, when they discuss
setting up an RMAN catalog, says to create an 'RMAN User' to own the
catalog... and then shows how to grant connect and resource to the new user.
You could well argue that this is merely sloppy courseware writing, but
it's a fairly good indication too that Oracle still sees a continuing
use for these things, so that dropping them would not be a particularly
wise move.
A quick search in the 9i official documentation also yields this quote:
"It is suggested that you create at least one additional administrator
user, and grant that user the DBA role, to use when performing daily
administrative tasks. It is recommended that you do not use SYS and
SYSTEM for these purposes."
That's from
http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96521/dba.htm
Regards
HJR
thoma...@oracle.com
disambiguate
to "remove ambiguation" :)
thoma...@oracle.com
Denis Do
(And this kind of advice is usually not free (if we are talking about some
3rd party commsec consultant):_))
I agree with DA Morgan, since I know some REAL cases of intrusion through
well-known pre-existing RESOURCE and DBA roles.
Besides of that, we are talking about PRODUCTION, so what relation those
rdbms/admin
scripts have to "official production environment"?
Even more, they MUST NOT BE there at all :-)
It is very similar like you still have gcc/make on production server ...
$-)
On Mon, 06 Dec 2004 08:17:04 -0800, DA Morgan <damo...@x.washington.edu>
wrote:
DA Morgan
Sort of like "swizzles references."
source:
http://download-west.oracle.com/docs/cd/B14117_01/appdev.101/b10802/d_ddl.htm#ARPLS008
Whatever he wishes to call it ... I very much appreciated the
clarification.
DA Morgan
> DA Morgan wrote:
>
> snip
>
>
>>I'd drop the DBA role completely as that is what Oracle advises. It
>>exists, like CONNECT and RESOURCE solely for demonstration purposes
>>just as does SCOTT/TIGER.
>
>
> I disagree. Securing access to oracle provided roles is one thing,
> recommending dropping the roles is another thing altogether.
>
> I for one have never heard anyone from oracle advising the DBA role
> should be dropped.
>
> John
My information has been corrected and I agree with respect to the
DBA role. I still think CONNECT and RESOURCE should be trashed.
Whether that means dropping them or just clearing out the privs
that are not appropriate is something each DBA should decide for
him or her self. My preference is to drop them.
Mark Bole
> Niall Litchfield wrote:
>
>>> 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.
>
>
> I agree. But I have read elsewhere specific advice to drop them as they
> are a security risk just by existing. Alternatively one can keep the
> roles but drop those privs from them that are inappropriate.
>
That's the problem -- you can't drop UNLIMITED TABLESPACE system
privilege from the RESOURCE role, because roles technically can't be
granted (or revoked) system privileges, and it's hard-coded anyway (an
"anomaly").
Isn't that how another thread recently got started here?
> I disagree that dropping CONNECT and RESOURCE will screw up any
> aspect of Oracle. But if you insist certainly one could edit those
> default roles to remove inappropriate privileges. What end-user,
> for example, needs the ability to create clusters and database links?
> And what DBA would want them to if they even knew what they were?
We need a future release of Oracle that commits to not using these
legacy roles out of the box (that is, upon install). The usual process
- first deprecated, then eliminated. Just like "sqldba" or "svrmgrl".
I think we're discussing the "deprecated" status....
--
Mark Bole
http://www.bincomputing.com
DA Morgan
Because they are security holes. Perhaps it is just me but I read
scripts before I run them and edit them where appropriate.
I absolutely fail to see why anyone would grant CONNECT knowing it
is giving each and every end user the ability to create a database
link. It may not be a problem where many of you work ... but in a
security conscious environment ... it just makes no sense: At least
to me.
DA Morgan
> I must admit, this is one REALLY good advice.
> (And this kind of advice is usually not free (if we are talking about
> some 3rd party commsec consultant):_))
>
> I agree with DA Morgan, since I know some REAL cases of intrusion through
> well-known pre-existing RESOURCE and DBA roles.
> Besides of that, we are talking about PRODUCTION, so what relation
> those rdbms/admin
> scripts have to "official production environment"?
> Even more, they MUST NOT BE there at all :-)
Thanks but having been corrected by Tom and reviewing it I agree that
the DBA role should not be dropped ... but also should not be assigned.
I too work in a high-security environment and am aware of break-ins and
break-in attempts using the default roles. I do believe CONNECT and
RESOURCE should be dropped or at least heavily pruned.
Then again I also don't install Oracle with a user account named Oracle.
Don't create groups named oinstall and dba on *NIX platforms and don't
use port 1521 so I guess that puts me well outside the curve.
DA Morgan
Likely we'll get that around the same time Oracle stops defining
trigger_body in dba_triggers as a LONG. ;-)
Anurag Varma
"DA Morgan" <damo...@x.washington.edu> wrote in message news:1102389346.899684@yasure...
Fine. Then tell me what privs you would really grant the outln, wmsys, oem_monitor, logstdby_administrator and csmig users? .. if
you
plan on dropping connect, resource from your database
What would you edit the above lines to?
How would you figure out what privs to grant by looking at a wrapped pl/sql code (see owmctab.plb above)?
mind reading I guess!
Anurag
Anurag Varma
"Denis Do" <nospam....@yahoo.com> wrote in message news:opsil9mq...@oicn055.internal.ozemail.com.au...
> I must admit, this is one REALLY good advice.
> (And this kind of advice is usually not free (if we are talking about some
> 3rd party commsec consultant):_))
>
> I agree with DA Morgan, since I know some REAL cases of intrusion through
> well-known pre-existing RESOURCE and DBA roles.
> Besides of that, we are talking about PRODUCTION, so what relation those
> rdbms/admin
> scripts have to "official production environment"?
> Even more, they MUST NOT BE there at all :-)
>
> It is very similar like you still have gcc/make on production server ...
> $-)
>
My response is on Daniels comment that dropping connect, resource will not screw up any aspect of oracle.
Just the presence of the roles in the database is not a security risk. Granting these roles to the users you create is not what I'm
advising.
I'm pointing out that oracle itself uses these roles to create some key users.
Also, I'm responding to his comment which does not seem Production specific.
Anurag
Niall Litchfield
news:1102382710.1...@c13g2000cwb.googlegroups.com...
> you are right, i did not need the "-"
> disambiguate
>
> to "remove ambiguation" :)
Your meaning was clear. I had just never seen the word before(hyphenated or
not). I would almost certainly have used clarify. I wondered if it was a
'separated by a common language' thing.
--
Howard J. Rogers
And a related question. When you've deleted the roles, and invented your
own substitutes, and stored outlines don't work or workspace management
produces odd results... and Oracle Support turns round and washes their
hands of you... what do you do then?
Regards
HJR
Niall Litchfield
I pointed out that the CTXSYS scripts use the roles you mention. Anurag
points out
sql.bsq
uowmu901.plb
a0801070.sql
c0703040.sql
c0800050.sql
catqm.sql
catsnmp.sql
catxdbr.sql
dbmslsby.sql
migrate.bsq
owmctab.plb
owmu901.plb
I just can't see that it is defensible to edit these scripts in the way
you describe. You'd have to edit sql.bsq to do it correctly and ensure
all subsequent scripts got changed appropriately (including as Anurag
points out the users that depend upon wrapped scripts). It clearly
would leave you with an unsupported system, even if you were lucky
enough to get away with setting your new roles up with the appropriate
privs. In a security conscious environment it makes no sense to have a
system that you can't support, possibly can't patch or upgrade.
> I absolutely fail to see why anyone would grant CONNECT knowing it
> is giving each and every end user the ability to create a database
> link. It may not be a problem where many of you work ... but in a
> security conscious environment ... it just makes no sense: At least
> to me.
That is an entirely different, and reasonable argument, of course good
practice is not to grant connect but a user defined role with
appropriate rights. Good practice is not to grant elevated os
privileges to people, it doesn't mean that the privileges get removed
from the os - it means they get used appropriately. Exactly the same
applies here. The 'existence' of powerful privileges is not a security
hole, the inappropriate grant and use of them is.
Niall Litchfield
I pointed out that the CTXSYS scripts use the roles you mention. Anurag
points out
sql.bsq
uowmu901.plb
a0801070.sql
c0703040.sql
c0800050.sql
catqm.sql
catsnmp.sql
catxdbr.sql
dbmslsby.sql
migrate.bsq
owmctab.plb
owmu901.plb
I just can't see that it is defensible to edit these scripts in the way
you describe. You'd have to edit sql.bsq to do it correctly and ensure
all subsequent scripts got changed appropriately (including as Anurag
points out the users that depend upon wrapped scripts). It clearly
would leave you with an unsupported system, even if you were lucky
enough to get away with setting your new roles up with the appropriate
privs. In a security conscious environment it makes no sense to have a
system that you can't support, possibly can't patch or upgrade.
> I absolutely fail to see why anyone would grant CONNECT knowing it
> is giving each and every end user the ability to create a database
> link. It may not be a problem where many of you work ... but in a
> security conscious environment ... it just makes no sense: At least
> to me.
That is an entirely different, and reasonable argument, of course good
practice is not to grant connect but a user defined role with
appropriate rights. Good practice is not to grant elevated os
privileges to people, it doesn't mean that the privileges get removed
from the os - it means they get used appropriately. Exactly the same
applies here. The 'existence' of powerful privileges is not a security
hole, the inappropriate grant and use of them is.
hpuxrac
is advocating any longer.
He seems to have acknowledged that recommending dropping the DBA role
was a very bad piece of advice.
Many people use these forums as sources of advice and wisdom.
It is probably a good idea not to recommend something like this to
others unless it is something that you have done in production and are
willing to offer a detailed plan.
Dan, have you dropped CONNECT and RESOURCE roles in production systems
or is this something theoretical at this point?
Academic discussions are all well and good but please make an effort to
clearly define to an audience that often does not have the background
that many of us do how much testing has gone into recommendations such
as these.
DA Morgan
It might be the exact same privs that are in CONNECT and RESOURCE. I
would have to make that decision when the time came. But I wouldn't
do it with the default role names that the entire world knows.
So I would create my own roles and then substitute those names for
CONNECT and RESOURCE.
DA Morgan
I am very well aware of several defense contractors and government
agencies that have dropped these roles and not one has been denied
support from Oracle. Thanks for the FUD.
davids...@gmail.com
>
> Then again I also don't install Oracle with a user account named
Oracle.
> Don't create groups named oinstall and dba on *NIX platforms and
don't
> use port 1521 so I guess that puts me well outside the curve.
> --
> Daniel A. Morgan
> University of Washington
> damo...@x.washington.edu
> (replace 'x' with 'u' to respond)
How is that any more secure? - Security by obscurity doesnt mean you
are secure
Also i dont agree with dropping any roles, dont like them - then dont
use them.
DA Morgan
Then let me clarify.
I routinely drop the CONNECT and RESOURCE roles when I install a
database. I wrote that DBA should be dropped too and was quickly and
decisively corrected by Tom Kyte and a correction that was well
deserved because it is not something I actually do and my writing was,
to put it mildly, sloppy. What I NEVER do is assign the role to anyone:
ever! I build application related DBA roles specific to what the actual
DBA is supposed to be doing and exclude any privs that are not required.
With respect to CONNECT and RESOURCE some have noted that these default
roles are used by Oracle as part of the installation of some components.
These are either components I don't use or I hand modify the scripts
before they are run to point to other roles that I create.
But in the end, no matter what system privileges I use to build a
production database I drop those privs after it is built that are not
required for it to be utilized. Then when changes to the schema are
required I put those specific privilege grants at the beginning of the
change script and revoke them again when the modifications are
completed. To have CREATE TABLE granted to a production schema where no
one should be creating tables is, to me, a danger without value.
Yes my way of doing things requires a bit of extra work: No question
about it. But then I often work in environments where security is more
important than saving an hour or two a month.
HTH
Howard J. Rogers
>> And a related question. When you've deleted the roles, and invented
>> your own substitutes, and stored outlines don't work or workspace
>> management produces odd results... and Oracle Support turns round and
>> washes their hands of you... what do you do then?
>>
>> Regards
>> HJR
>
>
> I am very well aware of several defense contractors and government
> agencies that have dropped these roles and not one has been denied
> support from Oracle. Thanks for the FUD.
If FUD means people don't do risky things, then I'm for FUD. I'm not for
mere anecdote about a few contractors and government agencies you happen
to be "aware of".
How many more times? The organisations of whom you write are highly
a-typical. Your advice should apply without qualification to the bulk
of users, not the little, select coterie you are "aware of".
HJR
DA Morgan
> DA Morgan wrote:
>
>>> And a related question. When you've deleted the roles, and invented
>>> your own substitutes, and stored outlines don't work or workspace
>>> management produces odd results... and Oracle Support turns round and
>>> washes their hands of you... what do you do then?
>>>
>>> Regards
>>> HJR
>>
>>
>>
>> I am very well aware of several defense contractors and government
>> agencies that have dropped these roles and not one has been denied
>> support from Oracle. Thanks for the FUD.
>
>
> If FUD means people don't do risky things, then I'm for FUD.
>
> HJR
FUD means do you actually have any experience with Oracle refusing
support to someone that dropped CONNECT and/or RESOURCE or are you just
trying to scare people?
Of course my experience is just my experience and not an official
statement from the Oracle Corporation. But I seriously doubt you
have actually had the experience of doing this and having Oracle
tell you to go pound sand.
And as I know you want the last word ... take it ... I won't respond
again as this is all I have to say on the subject.
DA Morgan
I can agree with you on the roles though I drop them just to force the
process of thinking through their replacements.
With respect to security through obscurity ... it is just one part of
a multilayered defense that starts with a firewall, utilizes logon
triggers, and many many other means.
Howard J. Rogers
> Howard J. Rogers wrote:
>
>> DA Morgan wrote:
>>
>>>> And a related question. When you've deleted the roles, and invented
>>>> your own substitutes, and stored outlines don't work or workspace
>>>> management produces odd results... and Oracle Support turns round
>>>> and washes their hands of you... what do you do then?
>>>>
>>>> Regards
>>>> HJR
>>>
>>>
>>>
>>>
>>> I am very well aware of several defense contractors and government
>>> agencies that have dropped these roles and not one has been denied
>>> support from Oracle. Thanks for the FUD.
>>
>>
>>
>> If FUD means people don't do risky things, then I'm for FUD.
>>
>> HJR
>
>
> FUD means do you actually have any experience with Oracle refusing
> support to someone that dropped CONNECT and/or RESOURCE or are you just
> trying to scare people?
Warn, Daniel. Warn. There's a difference.
> Of course my experience is just my experience
> and not an official
> statement from the Oracle Corporation.
I don't think any of us were in danger of confusing the two, Daniel.
> But I seriously doubt you
> have actually had the experience of doing this and having Oracle
> tell you to go pound sand.
Did I say that I had?
On the precautionary principle, Daniel, which do you think is more
appropriate? Telling people to go right ahead because a couple of giant
aerospace firms and a government department managed to get away with it?
Or telling people their support contracts may be at risk if they do it?
> And as I know you want the last word ... take it ... I won't respond
> again as this is all I have to say on the subject.
Whatever. You can try and make this personal if you want, but Niall says
you're wrong. Ana says you're wrong. I say you're wrong...
Get the picture?
HJR
Anurag Varma
"DA Morgan" <damo...@x.washington.edu> wrote in message news:1102438184.125096@yasure...
> Anurag Varma wrote:
>
> > "DA Morgan" <damo...@x.washington.edu> wrote in message news:1102389346.899684@yasure...
Oh ok. So you'll create roles with the same exact privs and will feel your db is secure.
Excellent!
Anurag
Anurag Varma
"DA Morgan" <damo...@x.washington.edu> wrote in message news:1102439319.800501@yasure...
So you say that you never really drop the DBA role and that it was sloppy writing?
How about the create database example in your site where you specifically advise dropping the DBA role?
Look at the last section in this page: http://www.psoug.org/reference/createdb.html
How about this?:
http://tinyurl.com/4kjle
where again you recommend dropping dba, connect and resource role .. and then claim that this is what oracle recommends!
Anurag
Howard J. Rogers
> So you say that you never really drop the DBA role and that it was sloppy writing?
>
> How about the create database example in your site where you specifically advise dropping the DBA role?
>
> Look at the last section in this page: http://www.psoug.org/reference/createdb.html
>
> How about this?:
> http://tinyurl.com/4kjle
>
> where again you recommend dropping dba, connect and resource role .. and then claim that this is what oracle recommends!
>
>
> Anurag
I think you are being a bit harsh, Anurag. You appear to be expecting a
level of consistency, competence, accuracy and precision from Daniel
that is entirely justifiable, but rather ambitious in his particular case.
As he writes elsewhere, he drops these roles and re-creates others which
contain the same privileges because he doesn't want to run his database
"with the default role names that the entire world knows." Perfectly
legitimate, of course... and no doubt, to be consistent, he drops SYS
and SYSTEM as users, too, since the entire world certainly knows about them.
It is self-evident that Daniel is somewhat tied up in inconsistent knots
on this entire matter. It is a little cruel of you to draw attention
to the fact, don't you think?
Regards
HJR
Denis Do
> Thanks but having been corrected by Tom and reviewing it I agree that
> the DBA role should not be dropped ... but also should not be assigned.
> I too work in a high-security environment and am aware of break-ins and
> break-in attempts using the default roles. I do believe CONNECT and
> RESOURCE should be dropped or at least heavily pruned.
>
> Then again I also don't install Oracle with a user account named Oracle.
> Don't create groups named oinstall and dba on *NIX platforms and don't
> use port 1521 so I guess that puts me well outside the curve.
This comment makes a good point.
Please consider the fact, that I am talking about HIGHLY secure
Oracle installation (that was a question in original post, wasn't it?)
Obviously, I do not delete DBA, resource and connect for average server,
working behind firewalls etc. In such situation everything you guys told here is
100% true.
But please see my point as well - if you want security - you must (and will) pay for it.
The more secure site - the less "out of the box" features you have and
less convenient your administrating day-by-day activity.
Are you really talking seriously about stored outlines, WM etc in highly secure system?
If you do - you are wrong, and any security cpecialist will confirm it.
In such system absolutely NO NEW FEATURES are installed after "golive date", no new
scripts run by DBA without supervision and nobody knows full password - just part of it.
And as for me, if you log into that system as SYSDBA, you will find there only 1/3 of
standard Oracle dictionary. Not even talking about DBMS_x packages etc.
YES, it IS unsupported and "risky", and 2/3 of cool latest Ora features will not work there,
yes - this DB is supposed to run ONLY pre-defined and tested subset of SQL statements and
pl/sql code - so what? That is the price you pay for real security.
And obviously, it is NOT recommended for public:_)
Just another point - I do respect all your opinions and never thought to try argue with you
- I am just demonstrating absolutely "untypical" configuration for highly-secure systems.
And, may be it is a surprise :_) - but I do have some servers running with DELETED DBA role.
They even report themselves as Ms SQL 2000 when you query v$version :-))
(that was a joke, sorry :-)
Please do not consider my post as offendive - it is my own IMHO :-)
Anurag Varma
"Howard J. Rogers" <h...@dizwell.com> wrote in message news:41b64d99$0$20858$afc3...@news.optusnet.com.au...
:) Right on.
I won't be surprised that his paranoia eventually leads him to start naming tables using unprintable characters.
just joking!
Anurag
Anurag Varma
"Denis Do" <nospam....@yahoo.com> wrote in message news:slrncrcpki.3q4...@denisdo.news.google.com...
Right! Its so highly secure that you can't stop telling us the details.
A little more prodding and I think you'll tell us the special sys password you chose for it also.
:) I'm just joking.
But seriously, I don't care whether you are running a database with the dba role dropped.
The question is not about it being possible or not .. but the sanity of the suggestion as a generic advise for everybody!
The comment by Daniel was generic. After all his create database example on his site explicitly directs
creating a database and then dropping the DBA role. I'm just wasting my time trying to make clear that this is
not a normal thing to do.
Anurag
Denis Do
>
> I won't be surprised that his paranoia eventually leads him to start naming tables using unprintable characters.
>
To be serious, I truly believe that if you are dealing with DB where,
lets say, 1mil of CC numbers are stored - there is no such thing as
paranoia. I prefer paranoidal DBA, who tends to over-complicate things,
to someone who will blindly follow setup guide and will bring company to
prosecution.
Is it good point or not? :-)
Howard J. Rogers
Well, it's missing the point. Daniel (merely as an example) is not
actually dropping the CONNECT or RESOURCE roles. Oh, he may be dropping
them under those names, but he is then creating identically-powerful (or
nealy so) roles with different names.
It's the existence of those powerful roles that's the issue, however,
for real security, not what they're called. And, especially, once you
conceed (as Daniel has, thankfully) that the DBA role stays put, under
that name, then piddling around with lesser roles is a complete waste of
time.
In a nutshell, the removal of these inbuilt roles, and their replacement
by renamed equivalents, is simply security through obscurity -which is
no security at all.
Regarding your specific suggestions, there is nothing wrong with
paranoia. But when your paranoia renders my database unsupportable or
unusable, I have a major problem with it! The 1 million credit card
numbers are presumably in your database because you intend to query them
and work with them. Dropping half the data dictionary, renaming Lord
knows what else, and doing everything else you describe would seriously
compromise that essential reason for having a database in the first place.
Given the Advanced Security features of Oracle; given
dbms_obfuscation_toolkit; given utlpwdmg; given everything else that is
available to a DBA to administer an Oracle database, there is precisely
zero need to wreck a database to make it "secure".
And whilst there may be incredibly rare exceptions to that rule, they
will not be ones that get talked about on a newsgroup; they won't be
running on Windows; and they don't justify going public with seriously
damaging advice for day-to-day use by general DBAs.
Regards
HJR
Denis Do
> A little more prodding and I think you'll tell us the special sys password you chose for it also.
>
If I am REALLY so annoying - sorry, mate( I do not think so,
however:-))
Do you really think that deleteion of DB schema is only
security step to be taken? :-)
And will it really help if I tell you "special sys pasword"?
Ok - write it down : "CHANGE_ON_INSTALL" :-)
I agree with you and I explicitely stated that before - it is not common
practice, it should not be done in everyday activty. I agree, so please
do not waste your time.
BTW, since we already started this topic - what would you, Anurag,
recommend to do for getting "out of the box installation"
reasonably secure? I really would like to know, please answer.
Also it will be good for others, and that can be kind of "What is
right thing to do" advice.
From my side, I would recommend (as DM did) do not use well -known roles
and accounts, create in your DB only those components, you really need and
never use DBCA.
And, thank you for your answers - even when we are "fighting" - we
all having fun, do we? :-)
Have a great day, guys!
Anurag Varma
"Denis Do" <nospam....@yahoo.com> wrote in message news:slrncrd15j.j0....@denisdo.news.google.com...
> On 2004-12-08, Anurag Varma <av...@hotmail.com> wrote:
> >
> > Right! Its so highly secure that you can't stop telling us the details.
> > A little more prodding and I think you'll tell us the special sys password you chose for it also.
> >
> Anurag, you are taking it personal - please do not.
> If I am REALLY so annoying - sorry, mate( I do not think so,
> however:-))
Relax.
If you read my reply carefully, you'll see that I state "I'm just joking" right after
I made the comments.
So you are the one who has started taking this seriously.
I'm responding to a specific piece of advice and thats it.
Anurag
DA Morgan
> Oh ok. So you'll create roles with the same exact privs and will feel your db is secure.
>
> Excellent!
>
> Anurag
Only if that is actually required. ONLY! So far I've never had to do it.
Howard J. Rogers
> Anurag Varma wrote:
>
>> Oh ok. So you'll create roles with the same exact privs and will feel
>> your db is secure.
>>
>> Excellent!
>>
>> Anurag
>
>
> Only if that is actually required. ONLY! So far I've never had to do it.
Please explain what on Earth is the point of dropping CONNECT and
RESOURCE if you are now conceding that the DBA role will be retained?
You're allegedly happy to retain a role which possesses 139 system
privileges (in 9i Release 2), but not a couple which possess 8 (ditto)?
You don't think, perhaps, that you are being just a teensy, weensy bit
illogical in your priorities?
HJR
DA Morgan
Credit card numbers is a good example.
So are design specifications for weapons systems.
So are medical records.
So are payroll and disciplinary records for employees.
So are records in a law enforcement agency on ongoing investigations.
So are records of pending and ongoing litigation at law firms.
And some companies that deal with defense issues are required by law
to not only secure specific defense related data but also data on
secondary uses. So, for example, since Air Force 1 is a Boeing 747 ...
by definition much of the information about 747's is classified.
Being security conscious is not being paranoid. There is a word for
people that don't understand the importance of security ... the word is
unemployable: At least where I consult.
Howard J. Rogers
A neat sashay away from the actual issue here: which is that your
previous approach to roles (the one you advocated before Tom put you
straight) provides zero security, but a support and management headache.
You current approach to roles (the one you adopted after Tom pointed out
your error) is just plain confused and represents the worst of both
worlds: keep the really powerful role, but drop the less powerful ones,
so no additional security; but still the support and management headache.
What any of that has to do with security, Lord only knows.
The word ought indeed to be 'unemployable'.
HJR
Niall Litchfield
> BTW, since we already started this topic - what would you, Anurag,
> recommend to do for getting "out of the box installation"
> reasonably secure? I really would like to know, please answer.
> Also it will be good for others, and that can be kind of "What is
> right thing to do" advice.
http://www.petefinnigan.com/orasec.htm would be an excellent place to start.
> From my side, I would recommend (as DM did) do not use well -known roles
> and accounts, create in your DB only those components, you really need and
> never use DBCA.
Why would you never use DBCA? At least to generate the initial scripts.
I'm also intrigued by your suggestion that once the database goes live you
should never touch anything again. Oracle patches exist for a reason -
security is one of them. If you *really* have dumped half the data
dictionary then almost certainly your db cannot be patched and is likely
less secure than if you'd followed sensible industry standard practices.
--
Anurag Varma
"DA Morgan" <damo...@x.washington.edu> wrote in message news:1102486526.559982@yasure...
ok .. now don't twist this thread into implying that I'm against security.
A paranoia which leads to a dba naming his tables as unprintable characters,
should actually be unemployable because that is a security measure with ZERO benefit
and instead leads to a administration nightmare.
Anyone who does not agree with you is pretty much unemployable in your part of the world.
You throw that statement around quite lot. I guess over time, arrogance has taken quite a strong hold over you.
Wherever that is... I would not want to be employed there if questioning illogical statements there was wrong!
Anurag
Frank van Bortel
> Anurag Varma wrote:
>
>> So you say that you never really drop the DBA role and that it was
>> sloppy writing?
>>
>> How about the create database example in your site where you
>> specifically advise dropping the DBA role?
>>
>> Look at the last section in this page:
>> http://www.psoug.org/reference/createdb.html
>>
>> How about this?:
>> http://tinyurl.com/4kjle
>>
>> where again you recommend dropping dba, connect and resource role ..
>> and then claim that this is what oracle recommends!
>>
>>
>> Anurag
>
>
> I think you are being a bit harsh, Anurag. You appear to be expecting a
> level of consistency, competence, accuracy and precision from Daniel
> that is entirely justifiable, but rather ambitious in his particular case.
>
> As he writes elsewhere, he drops these roles and re-creates others which
> contain the same privileges because he doesn't want to run his database
> "with the default role names that the entire world knows." Perfectly
> legitimate, of course... and no doubt, to be consistent, he drops SYS
> and SYSTEM as users, too, since the entire world certainly knows about
> them.
>
He never said that! And he has also admitted he was wrong about the
advice to drop the DBA role.
So, it's only naturally you can come up with a link that still has
this (now admittingly wrong!) advice.
It's like taking a lolly from a baby.
> It is self-evident that Daniel is somewhat tied up in inconsistent knots
> on this entire matter. It is a little cruel of you to draw attention to
> the fact, don't you think?
>
So did you - by replying.
Get off it, children! Playtime is over, no more playing in the sandbox.
--
Regards,
Frank van Bortel
Howard J. Rogers
I didn't say he did, Frank. In fact, my point works precisely because he
*didn't* say that. I am pointing out that he is on record as saying that
he drops CONNECT and RESOURCE because they have well-known names. Well,
*to be ocnsistent*, he should then advocate the renaming of SYS and
SYSTEM, since they are very well-known names too! But (obviously quite
sensibly) he doesn't... which, therefore, rather undermines the argument
he uses for 'renaming' CONNECT and RESOURCE and means that his advice on
those roles is ipso facto inconsistent.
> And he has also admitted he was wrong about the
> advice to drop the DBA role.
He hasn't, actually. He blamed it on sloppy writing, not on being wrong.
But that's a side show. The DBA role is *one* of *three* roles he has
advocated dropping. He's backed off on the DBA one, but that leaves two
to go. He's still arguing that those should be dropped.
> So, it's only naturally you can come up with a link that still has
> this (now admittingly wrong!) advice.
I am not sure what advice or what link you're talking about. But you
imply that I am underhandedly linking to out-of-date information in
order to do down Daniel. That is not so. Daniel is STILL advocating the
dropping of two roles which he shouldn't be. That is very much current
information. Dropping those roles and re-creating them, or something
very like them, under new names is NOT recommended by Oracle; is NOT
actually going to increase security; MAY break your database; MAY
compromise your support contract.
> It's like taking a lolly from a baby.
Again, I don't really understand what you mean by that. But if you mean
'this is too easy', I can only reply "if only". Trying to get Daniel to
admit that his advice is wrong, flawed, erroneous, dangerous,
ill-advised, unsupported and pointless in the first place is a very tall
order indeed.
>> It is self-evident that Daniel is somewhat tied up in inconsistent
>> knots on this entire matter. It is a little cruel of you to draw
>> attention to the fact, don't you think?
>>
>
> So did you - by replying.
> Get off it, children! Playtime is over, no more playing in the sandbox.
Frank, if there's one thing I can't stand, it's people butting into
threads and declaring the topic over. It's over for me when I consider
the damage and the danger to have passed. It hasn't. Daniel is still
pushing ludicrously self-contradictory advice that will do HARM to
databases. If you think that's playing, you don't understand.
And if in the process of dealing with his dangerous advice I happen to
share a subtle bit of irony with Anurag, that's my affair, not yours.
Particularly when the irony seems to have sailed straight over your head.
HJR
Jeff
>I am not sure what advice or what link you're talking about. But you
>imply that I am underhandedly linking to out-of-date information in
>order to do down Daniel. That is not so. Daniel is STILL advocating the
>dropping of two roles which he shouldn't be. That is very much current
>information. Dropping those roles and re-creating them, or something
>very like them, under new names is NOT recommended by Oracle; is NOT
>actually going to increase security; MAY break your database; MAY
>compromise your support contract.
Trying to be a better DBA, I actually tried dropping those roles on a test
database (used by developers, not production). And it didn't take long for me
to realize the mistake... the next time I patched the database with a new
version, in fact. ;-) Needless to say, I leave those roles alone now. I
don't grant them to just anyone, willy nilly (never did, actually), but
they're there to stay.
Frank van Bortel
Oh yeah, Howard - the irony sailed over my head, indeed.
So it might have with others, too.
It looked to me like as Daniel bashing, once more. Of course,
you are right when you are right; and when he is wrong, you
are free to correct him (or me, or whom ever, for that matter).
But please keep it technical, please.
And as you use this ng for your irony, it's my affair as well.
Send private emails if you don't like the rest of the world to
read it.
If you would have read the links, you would have understood
the comment, and that was NOT you, by the way, doing the linking.
For all clarity: Anurag provided the link, not you. So I implied
nothing - you implied I implied something, even when admitting
you do not understand the matter.
The irony you failed to understand is that all I wanted is to
stop throwing mud (sand box - get it?) to each other.
I wished that would stop, here - that's all there's to it.
[completely OT]
Howard, life is short, let's enjoy it - I'll see if I can find
a fine bottle of Australian wine (think not - they never survive
long... :) ), and I'll toast to your health.
Even if you don't give s**t about it.
Cheers!
[/OT]
--
Frank van Bortel
Howard J. Rogers
> Oh yeah, Howard - the irony sailed over my head, indeed.
> So it might have with others, too.
> It looked to me like as Daniel bashing, once more.
That's because it is advice-bashing, and Daniel happens to be the one
giving the advice.
> Of course,
> you are right when you are right; and when he is wrong, you
> are free to correct him (or me, or whom ever, for that matter).
> But please keep it technical, please.
I have. Carefully so.
> And as you use this ng for your irony, it's my affair as well.
> Send private emails if you don't like the rest of the world to
> read it.
Don't hit the reply button when you don't understand it Frank. The cap
fits both ways on that one.
> If you would have read the links, you would have understood
> the comment, and that was NOT you, by the way, doing the linking.
Oh, so you accuse me of something I didn't actually do? Is this another
example of "I was writing to the world at large and using a reply to you
to do it in"?? Silly me... I must remember to take the ESP and
mindreading pills when you post!
> For all clarity: Anurag provided the link, not you. So I implied
> nothing
Oh, OK. You just posted completely erroneous information. I see. That
makes it all alright, then.
> - you implied I implied something, even when admitting
> you do not understand the matter.
Frank: you wrote (in a reply to a post of mine):
'You come up with a link that still has thiks wrong advice'
The word "you" means something Frank. If you don't mean it, don't post it.
And try and understand the English language. I didn't imply anything
about you or your intentions. I stated in black and white that you were
suggesting I was being underhand. No implying on my part was done.
> The irony you failed to understand is that all I wanted is to
> stop throwing mud (sand box - get it?) to each other.
> I wished that would stop, here - that's all there's to it.
I just wish you'd go away and busy yourself with technical threads that
demand your close attention. This one doesn't. I need no advice from you
about how to post, what to post, or to whom my posts should be
addressed. You, however, could do with some remedial work on most of
those issues.
I don't care one whit if you think this is playground stuff, a sandbox,
throwing mud or whatever... you're wrong. This is Daniel offering wrong,
dangerous, unsupported advice. I'll call that as it is, and if you don't
like it, you can go away and stop reading it. I'd call it dangerous,
unsupported and self-contradictory advice if *you* offered it; if Don
Burleson offered it; if anyone at all offered it. If you want to read
that as an attack on Daniel, then be my guest. It isn't. He can just
retract the erroneous advice, and then the issue goes away.
But it doesn't go away just because you lumber into a thread saying it
should.
> [completely OT]
> Howard, life is short, let's enjoy it - I'll see if I can find
> a fine bottle of Australian wine (think not - they never survive
> long... :) ), and I'll toast to your health.
Please don't bother. This isn't a tea party or a social event. I don't
know why you post here. But I know why I do. It's to help people with as
accurate advice as I can muster, and to learn: and when I see *harmful*
advice being offered, I call it like it is.
You can reply if you like, but you'll hear nothing back from me on the
matter.
HJR
Alan
"Niall Litchfield" <niall.li...@dial.pipex.com> wrote in message
news:41b5530d$0$16575$cc9e...@news-text.dial.pipex.com...
> thoma...@oracle.com> wrote in message
> news:1102382710.1...@c13g2000cwb.googlegroups.com...
> > you are right, i did not need the "-"
> > disambiguate
> >
> > to "remove ambiguation" :)
>
> Your meaning was clear. I had just never seen the word before(hyphenated
or
> not). I would almost certainly have used clarify. I wondered if it was a
> 'separated by a common language' thing.
"Never use a big word when a diminutive one will do." -William Safire