Re: "oracle" lockdown
- From: Seth Miller <sethmiller.sm@xxxxxxxxx>
- To: "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 26 Feb 2014 17:06:01 -0600
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
>
Other related posts:
