Re: User equiv and "oracle" lockdown
Date: Mon, 22 Sep 2014 15:31:34 -0500
Message-ID: <CAEueRAWihBaAo+8Wn+zFDEXHaUktuAT8KxG8qAKf0hHsd=F=ow_at_mail.gmail.com>
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_at_comcast.net> 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_at_comcast.net
> View Matthew Parker's profile on LinkedIn
>
>
> -----Original Message-----
> From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
> On Behalf Of Herring, David
> Sent: Monday, September 22, 2014 12:27 PM
> To: oracle-l_at_freelists.org
> 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
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>
-- http://www.freelists.org/webpage/oracle-lReceived on Mon Sep 22 2014 - 22:31:34 CEST