Oracle lockdown and EM Jobs

From: "Herring, David" <HerringD@xxxxxxx>
To: "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
Date: Wed, 9 Apr 2014 11:20:56 -0500
Folks,

About 2 months ago I made a post related to our company's effort to lockdown 
"oracle" access on all our machines, preventing direct logons and creating a 
shell.  I've now come across an issue with how EM Job commands are executed and 
I'm curious if anyone else has run into this.

We have a number of EM Jobs that need to run as "oracle".  (Why?  See "Why"? at 
the end of this email.)  Our individual accounts have permission to run 
commands as "oracle" using the syntax: 
        sudo -u oracle <cmd>

Under 10.2.0.4 of EM and above we have the ability to set a privileged 
delegation provider so that we can set credentials to use either "sudo" or 
power broker.  I've configured this for "sudo", set my preferred credentials to 
"Run as..." to be "oracle", so all appears fine.  The problem comes in when 
running an EM Job.  I'm getting the error:

        'Sorry, user herringd is not allowed to execute '/bin/sh -c . 
<command>' as oracle on <server>.

I set tracing on authentication in emd.properites and after reviewing 
emagent.trc I could see that the agent is trying to run:

        sudo -u oracle /bin/sh -c . '<command>'

So the agent is trying to run the command as "oracle" in a new shell, which we 
can't do since "oracle" isn't allowed to create a shell.

Is anyone running EM Jobs, using "sudo" to run as "oracle", AND have the 
"oracle" account locked down so it can't create a shell?

#-------|
# Why?
#-------|
Although Oracle is designed so that with the correct ownership, group, and 
permissions individual DBA accounts SHOULD be able to run nearly everything 
they need as part of day-to-day support, we have hundreds of installs that are 
not set up this way.  Our individual accounts will not be granted the group 
"dba" (first of many battles I've lost).  Group ownership of installs is 
"oinstall", which our accounts will have but unfortunately permissions across 
the install don't always include g+x so we'd have to modify permissions, which 
I'm not comfortable doing, especially with production.  I have a feeling that 
possibly every install was done via the GUI, which means there is possible 
variance amongst the installs.  My plan is to institute a more repeatable, 
silent, cloned, provisioned, ... approach but that's not set up yet nor does it 
help with the current installs.

Dave Herring

--
//www.freelists.org/webpage/oracle-l
Oracle lockdown and EM Jobs

Other related posts:
