RE: "oracle" lockdown
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 27 Feb 2014 09:18:43 -0500
Actually, the subtle difference between what you need and what some of us
thought you wrote you need is healthy to raise and consider from time to
time. So thanks for the thread and thanks Hans for your rant.
I am continually thankful that debates and clarifications on this list, no
matter how passionate or blunt, nearly never get to flames.
If you start projects properly locked down and do things like moderately
frequent password change requirements from the beginning of a project, it is
far easier than locking down something already built. See the asynchronous
bit of this thread from Niall about one aspect of that.
I see the situation as binary: Either something is a complete "sandbox" you
never hope to or even possibly plan to lock down or ever promote into
production or it is not. If it is not a sandbox, your total project cost
from inception to retirement will likely be less locking it down from the
beginning, so no one accidentally builds utilities that violate security
(and not having understood they violate security, did not document the
"special" requirement.)
mwf
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Herring, David
Sent: Wednesday, February 26, 2014 10:11 PM
To: fuzzy.graybeard@xxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: RE: "oracle" lockdown
If I said this is a problem I apologize for misstating the situation and I'm
sorry for forcing you to rant. I was just wondering who else has gone
through this and what to watch out for.
Dave Herring
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Hans Forbrich
Sent: Wednesday, February 26, 2014 7:27 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: "oracle" lockdown
I'm not sure what the problem is - Oracle database was designed to be
administered by administrators using their own OS userid with checks that
they are in the appropriate Administration OS group and this has been
available since half of forever.
Other than installation and some patching, there generally should be no
reason to log in as Oracle.
<rant>
Indeed, the common habit (by many shops I visit) for DBAs to log in as user
Oracle is terrifying from a security perspective - everyone in the DBA team,
and potentially others, has the keys to the kingdom and there is absolutely
no non-repudiation. No way at all to tell which admin did which command;
everyone scrambling to get the changed password; getting an exception to the
corp password change lifecycle policy; etc. And when a DBA leaves the
group, the common-knowledge super user password needs to be changed, but
often is not ...
Even in my lab, I have a non-'oracle' Oracle Administrator which I use for
most admin (which seems silly in a one-man lab).
There is a reason we are forced to run root.sh during installation - mainly
to chown files and setGID and config for 'sysdba' and 'sysoper' - to support
DBAs and other support personnel using their own IDs. With 12c, they have
given us additional groups to further refine the granularity.
ASM and GI take this a major step forward as well. In big shops with
division of responsibility, that can be very useful although for small shops
it get very cumbersome - "to run this I log in as A, but to run that I log
in as B'. At that point Cloud Control and it's security model becomes very
interesting.
A secondary variation on this - I also install an ORACLE_HOME specifically
for the Oracle Client (sqlplus, etc) under user 'oraclient'
(under a different tree - /u01/app/oraclient) which is not in OSDBA group to
support batch jobs and non-admin users who need access to the machine.
Users who log in then set up the environment for that and use Oracle
Networking tcp, rather than bequeath adapter. That, however, can be a
challenge for some things.
</rant>
I would encourage the OP to set up a test user in the OSDBA group and check
out the core scripts they run. Based on my experience, most of them should
run just fine as long as the user is created properly and the environment is
set up properly. I'd be interested in hearing under which circumstances
this fails.
/Hans
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
