RE: "oracle" lockdown
- From: "Herring, David" <HerringD@xxxxxxx>
- To: "sethmiller.sm@xxxxxxxxx" <sethmiller.sm@xxxxxxxxx>, "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 26 Feb 2014 21:05:50 -0600
Seth,
I don't think I stated anywhere that I NEED to run something as "oracle", only
the assumption that some commands must be run as "oracle". If I stated the
former then I apologize. If nothing but the install needs to be run as
"oracle" then we're fine for nearly all cases. I'm not aware of what commands
need to run as "oracle" - just assumed some do.
It'd be great if all the installations were set up with the intent of division
of duties but they weren't, so I'm stuck with what we've got.
Dave Herring
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Seth Miller
Sent: Wednesday, February 26, 2014 5:06 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: "oracle" lockdown
Dave,
The product was designed so you don't need access to the installation account
(oracle) unless you're doing things like installation.
Can you forward a list of commands that you believe you need the oracle account
to execute? Perhaps the folks here can show you how to avoid using the oracle
account all-together.
Most things not directly related to the binaries should not be installed with
the oracle user. For example, EM agents should be installed with a separate
user. Jobs also should be executed as a separate user so you don't need to use
oracle's crontab.
Seth
On Wed, Feb 26, 2014 at 4:42 PM, Herring, David <HerringD@xxxxxxx> wrote:
Not exactly. Both our individual accounts and "oracle" will have both groups
(dba and oinstall). In our case the goal is to isolate shared accounts and
track their usage. There's a side effort with this to use a RedHat directory
server for centralizing permissions at the Linux-level but I'll leave that one
for another day.
In terms of setting my env, I can set all the variables I want but what the
Linux guys are telling me is that when I "sudo" something as "oracle", only a
bare minimum of env variables will be set. So I could have $ORACLE_SID,
$ORACLE_HOME, $PATH, ... set to specific values but if I run "sudo -u oracle
x.sh", the script x.sh won't have the $ORA* variables set and $PATH could be
different, probably just whatever is set in /etc/profile.
So based on the above and the fact I can only pass 1 command to the "sudo"
command, I've got to figure out a way to set my env appropriate with the
matching command I want executed as "oracle". Not all commands need to be run
as "oracle" but I need to factor in we've got agents on every server, have
single nodes and RACs up to 9 nodes, we've got some RACs with 2 to 6 database
spread across them, releases 9i through 11g, data guard, OGG, etc. Definitely
EM console and Jobs will be my friend, assuming the agent itself won't have
issues.
Dave Herring
From: Andy Wattenhofer [mailto:watt0012@xxxxxxx]
Sent: Wednesday, February 26, 2014 4:13 PM
To: Herring, David; oracle-l@xxxxxxxxxxxxx
Subject: Re: "oracle" lockdown
It appears to me that the changes you are facing are to enforce role
separation, for security purposes. That is the purpose of having the two dba
and oinstall groups created as part of the Oracle install process. It permits
separation between the software owner (oinstall) and the database administrator
(dba).
If your login id is a member of the dba group, you should be able to run
everything under your own id. In theory, you could get by without sudo except
for patching and install operations, which require oinstall group. The oracle
user id is a member of oinstall.
You can source the .bash_profile from the oracle user in your own .bash_profile:
. /home/oracle/.bash_profile
(you'll probably have to adjust some file permissions before that will work).
Andy
On Wed, Feb 26, 2014 at 2:19 PM, Herring, David <HerringD@xxxxxxx> wrote:
Folks,
Our team is about to be placed in a more challenging situation where the OS
account "oracle" will be locked down in the following ways:
1) No direct logons.
2) No shell can be created by "oracle".
3) Execution as "oracle" can be done by DBA accounts using: "sudo -u oracle
<cmd>".
I'm tasked with coming up with a test plan for each environment converted over
to this configuration. While I can come up with the various commands we
typically use off a consolidation of ~/.bash_history on all servers, I'm
concerned about the environment when running "sudo - u oracle". I'm told that
there's no guarantee on what env variables will be set so if I expect any
particular values I'll have to put it all in a script, since we can't run
multiple commands on one line (like "sudo -u oracle export ORACLE_SID=dave;
export ORAENV_ASK=NO; .oraenv; ...").
My first thought is we'll need some sort of wrapper script, with arguments for
the ORACLE_SID and command line to run. Has anyone run into this type of
situation and if so how did you handle it? There's still no word on how we're
going to manage interactive installs. I feel like I'm on the Indians in the
movie "Major League".
Dave Herring
--
//www.freelists.org/webpage/oracle-l
--
Andy Wattenhofer
Manager, Database Administration
University of Minnesota
--
//www.freelists.org/webpage/oracle-l
Other related posts:
