Re: Oracle lockdown, agents, and EM Jobs

$AGENT_HOME/bin/emctl needs to be run as the owner of the executable. It does not and should not be owned by oracle. It is very easy to change the owner of the agent and since the agent has no authority to do anything outside of itself without sudo, there should be no problem with giving everyone access.

Do you not use password files? Why would you need access to the dba group for sysdba? Once you move into multi-tenant, os authentication goes away for PDBs so you may want to ween yourself off of that anyway. Using the oracle user to login as sysdba also has the added consequence of not being able to track actions against users in the database.

Sudo has a parameter called "env_reset". Disabling this parameter is less secure than leaving it enabled. Has your Unix group explained why they are denying you this parameter?

Seth

On Wed, Jun 18, 2014 at 9:58 PM, Herring, David <HerringD_at_dnb.com> wrote:

> Seth,
>
> Now I feel REALLY bad because I had such grand plans for blogging yet
> never seem to find time for it. I was just glad to finally read through
> the lastest posts on this list!
>
> In terms of what needs "sudo" and what doesn't, I'm not so sure things are
> as clean. Nearly everything was installed over time using defaults, so at
> this point I'm assuming permissions and ownership hasn't been messed with.
> But what I've found is even simple things like $AGENT_HOME/bin/emctl needs
> to run as "oracle". Most binaries under $ORACLE_HOME are fine but our team
> has been denied group "dba", so we have to run as "oracle" to use "sysdba".
> I'll definitely have to find time or rope another DBA into reviewing our
> scripts to see which commands within them really need to run as "oracle"
> and then comment them accordingly so that it's documented which way is
> required.
>
> Concerning "sudo" and variables, we're only allowed "sudo -u oracle
> <cmd>". So it's not whether or not sudo is set up right but what we've
> given. This method runs the command as "oracle" but doesn't change the
> environment so the whole inheritance of settings comes in to play. This
> has caused some rather confusing debugging sessions for me, such as when I
> restarted an agent and my env had a custom setting for $TNS_ADMIN. "%
> strings /proc/<agent pid>/environ" becomes very handy in this case!
>
> As for the credential comment to Tony, this is again a security issue.
> We're not allowed a shared/common account at the OS. That means if
> credentials are needed at the OS level then they must be individual DBA
> credentials. I at least have been allowed to have a common EM admin so
> this user then owns everything in the Job Library and is used for all
> submitted Jobs. But this is a good reminder to me to see what alerts can
> be sent us from the RH LDAP server on upcoming password expirations.
>
> Dave Herring
>
> From: Seth Miller [mailto:sethmiller.sm_at_gmail.com]
> Sent: Wednesday, June 18, 2014 8:47 PM
> To: dedba_at_tpg.com.au
> Cc: Herring, David; oracle-l_at_freelists.org
> Subject: Re: Oracle lockdown, agents, and EM Jobs
>
> David,
>
> Kudos to your organization for taking this on. I hope you will share this
> experience with the community through blogs and presentations. I could see
> these topics easily being accepted as a presentation at any of the
> conferences.
>
> With the exception of a very few (and by very few I mean less than five)
> situations, there should not be any scripts that need to run as oracle. I
> am including the EM agent as one of those things that does not require
> oracle. Those few things that are required to be run as oracle should be
> done through sudo. If executing something using sudo is leaving environment
> variables in place that shouldn't be there, then sudo is not set up
> properly.
>
> Your messages were quite complex but you are asking very good questions
> here. I suggest you break it down into one or two issues per post and hash
> them out before moving to the next issues.
>
> Tony,
>
> You're quite right that jobs that need to persist across employees should
> never be run with credentials of an individual. Jobs should be run under a
> common system user. As long as no one can use this user for anything other
> than jobs (no local access to the servers), security would not be an issue
> since authorization and auditing is taken care of with EM. If separation of
> duties is the issue, each individual could have their own system user that
> could just be reassigned to someone else if necessary.
>
> Seth
>
>
> On Wed, Jun 18, 2014 at 7:59 PM, De DBA <dedba_at_tpg.com.au> wrote:
> This is becoming a very interesting story indeed. How about putting the
> common oracle environment in a file in a common location, e.g.
> /var/opt/oracle/oraenv.sh, and having each script and perhaps
> .bashrc/.bash_profile source that as appropriate? Access to this directory
> should already be allowed. We tend to do this, even where security is not
> as overzealous as what you're facing. It just makes managing environments
> more easy when everything is in one common location, whilst allowing DBAs
> to choose whether to use the common environment or not.
>
> I wonder how you are going to set up EM jobs that need os logon
> credentials. If you use a DBA's credentials, then those jobs will start to
> fail when the DBA in question leaves the organisation and his account gets
> disabled or removed from the directory.. Could be an administrative
> nightmare waiting to happen?
>
> Cheers,
> Tony
>
>
> On 19/06/14 08:18, Herring, David wrote:
> Options:
>
> 1) Every DBA has their own .bash_profile created as a copy of Oracle's.
> This is what I started with thinking it was simple but after one week I've
> found 2 examples where DBAs didn't bother to follow this rule. I can't
> control them and have no authority to force them to do anything other than
> the bare minimum of their job.
>
> 2) Open permissions on /user/oracle (710) and /user/oracle/.bash_profile
> (750) so that each EM Job could issue at the start: ".
> ~oracle/.bash_profile". So whether daveh or markb or timg have their
> credentials set for the target, all can execute Oracle's .bash_profile and
> we're fine.
>
> Everything else I've come up with is a variation on the above 2 options,
> either modifying DBA .bash_profiles in some way or something within
> Oracle's home directory that requires permissions to be relaxed a bit.
>
> Does this make sense?
>
> Am I making this overly complex?
>
> Anyone else in a similar situation and have a better solution?
>
> Dave Herring
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

--
http://www.freelists.org/webpage/oracle-l