RE: User equiv and "oracle" lockdown
- From: "Dimensional DBA" <dimensional.dba@xxxxxxxxxxx>
- To: "'Herring, David'" <HerringD@xxxxxxx>, "'Seth Miller'" <sethmiller.sm@xxxxxxxxx>
- Date: Mon, 22 Sep 2014 14:51:46 -0700
That is standard passwordless ssh setup. You are misreading that there is a
passphrase generated for each connection that you must enter.
Matthew Parker
Chief Technologist
425-891-7934 (cell)
Dimensional.dba@xxxxxxxxxxx
View Matthew Parker's profile on LinkedIn
-----Original Message-----
From: Herring, David [mailto:HerringD@xxxxxxx]
Sent: Monday, September 22, 2014 2:26 PM
To: Seth Miller; dimensional.dba@xxxxxxxxxxx
Cc: Oracle-L Freelists
Subject: RE: User equiv and "oracle" lockdown
Np. Here's the link I was sent:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s2-ssh-configuration-keypairs.html.
This link just shows changing over from password authentication to using pass
phrases that are good only for your current session.
Unfortunately I'm in an environment where any DBA access is guilty until proven
innocent. I tried to convince them that locking down a system that isn't even
fully functional, much less not having any front-end access is rather silly but
they wouldn't budge.
Dave Herring
From: Seth Miller [mailto:sethmiller.sm@xxxxxxxxx]
Sent: Monday, September 22, 2014 3:32 PM
To: dimensional.dba@xxxxxxxxxxx
Cc: Herring, David; Oracle-L Freelists
Subject: Re: User equiv and "oracle" lockdown
I would agree on posting the documentation they are citing. There are very few
methods of authentication that are more secure than shared-key and I doubt they
are proposing any of them.
If security is the issue, there are all kinds of fruit within reach to start
picking rather than trying to reach to the top of the tree for this issue.
Seth Miller
On Mon, Sep 22, 2014 at 3:02 PM, Dimensional DBA <dimensional.dba@xxxxxxxxxxx>
wrote:
I would ask them for the specific Red Hat documentation. I have been in many
discussions with Linux teams and found their documentation to be old or not
specific to Oracle and normally there are specific ones to Oracle that states
how you must do things.
If you have the specific documentation they are using can you share the Red Hat
note numbers. I would be more than happy to pull you the Red Hat documentation.
One Example is
https://access.redhat.com/sites/default/files/attachments/oracle_11gr2_on_rh
el6_0.pdf
4.2.9 Security Settings and Recommendations Best practices for initial set-up
for database security are straightforward, but ongoing security-or security as
a process-is more difficult to summarize. Briefly, use root powers sparingly.
Oracle has separated and grouped root actions; e.g., a small set of
pre-installation tasks and a small set of post-install fix-up scripts. Do not
use application accounts as your normal account; that is, log onto the database
host as a non-generic, named user (jqbach, for example), and when database
tasks are needed, use sudo or su to switch to the application
(oracle) account.
These extra steps require discipline to follow (because the alternatives
require fewer keystrokes), but the benefit lies in preventing accidents that
might cause significant amount of time to correct, and in providing a simple
log of who has done what and when.
Matthew Parker
Chief Technologist
425-891-7934 (cell)
Dimensional.dba@xxxxxxxxxxx
View Matthew Parker's profile on LinkedIn
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Herring, David
Sent: Monday, September 22, 2014 12:27 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: User equiv and "oracle" lockdown
Does anyone know all areas where user equivalency for the account "oracle"
is necessary in a RAC system, let's say 11g and above on Linux RH?
The reason I ask is that our security team is now refusing to have this set up
and even though I passed snipets from Oracle doc which states "it must be set",
they're balking and sending snipets from RedHat doc saying that's unwise.
Without user equiv for "oracle" I believe the following will break/have
issues:
* Proper management agent monitoring. The agent needs to know it's a RAC to
properly monitor the configuration. I don't have specific examples, just
oddity with agent behavior when user equiv isn't set properly.
* All "cluvfy" uses will fail. Most are interactive uses but the management
agent uses it too for cluster verification. So in a way almost all our ability
to validate the cluster will be unavailable.
* All installs, patches, upgrades will fail or least be a complete hack.
Rolling patch application would never be possible, I assume.
I know the cluster will still work without user equiv as I've run into enough
existing systems where the DBA didn't do it properly or didn't properly add new
nodes. Is there anything else that would break/be a major pain? Since
documentation proof isn't enough I need to explain in (my) painful detail of
why we need it.
Dave Herring
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
