Re: DBAs running root.sh
- From: Niall Litchfield <niall.litchfield@xxxxxxxxx>
- To: "Amaral, Rui" <Rui.Amaral@xxxxxxxxxxxxxxxx>
- Date: Mon, 3 Feb 2014 17:42:05 +0000
I think the SA's argument is this.
root.sh is an executable shell script owned by oracle and therefore
modifiable by oracle - a non-privileged user could therefore use root.sh as
an attack vector against the server. This is, as far as I can tell,
correct. Whether it is any more of a threat than the dba being able to run
arbitrary code with the privileges that the oracle account has seems
unlikely to me. I'd probably suggest a round table meeting between the O/S,
DBA and Security subject matter experts to agree a solution..
As the scripts generated contain the ORACLE_HOME path in them I think the
suggested approach likely to be problematic, clearly one could edit root.sh
(and all the scripts that it calls nowadays) to take, say, $ORACLE_HOME as
an argument and then have an authorized central repository of them, good
luck with the support ticket when something is missed though.
Interesting question Austin.
On Mon, Feb 3, 2014 at 5:27 PM, Amaral, Rui <Rui.Amaral@xxxxxxxxxxxxxxxx>wrote:
> For us it's option 1 where the SA runs it on our behalf. We have tried to
> get sudo but that was not allowed to us for root.sh though it is for some
> of the RAC tools (like srvctl) on some of our environments. Like Chris
> mentioned sudo can be configured to run only that one file but in our
> environment there is a lengthy security process to follow to allow this
> that we stopped trying.
>
>
>
> Rui Amaral
>
> Tower Lead, Database
>
>
>
> *From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto:
> oracle-l-bounce@xxxxxxxxxxxxx] *On Behalf Of *Chris Taylor
> *Sent:* Monday, February 03, 2014 12:15 PM
> *To:* hacketta_57@xxxxxx
> *Cc:* oracle-l digest users
> *Subject:* Re: DBAs running root.sh
>
>
>
> sudo is setup to limit what you can run - so even if you have sudo access
> and you modify the root.sh script, you can still _only_ run what you have
> sudo access to do. So, as long as your sudo setup is correct, there is
> nothing you can do in the root.sh script that can cause damage. Another
> way to look at it - if you have sudo access and there is something damaging
> you can do, you can do it without modifying the root.sh script. The
> dependency here is that sudo is setup correctly.
>
>
>
> Chris
>
>
>
>
>
> On Mon, Feb 3, 2014 at 11:08 AM, Austin Hackett <hacketta_57@xxxxxx>
> wrote:
>
> Hi List
>
> If you work in a security conscious environment, I'd be keen to hear how
> your site handles the root.sh script.
>
> To give you some background:
>
> In my environment, DBAs are currently given direct root access to allow
> them to run root.sh. However, the SA Team would like to tighten this up. If
> giving the DBAs direct root access isn't acceptable (not even temporarily)
> then two options spring to my mind:
>
> 1) SA team run root.sh on behalf of the DBAs. Geography and logistics in
> my organisation are such that having an SA walk over to the DBAs desk is a
> realistic option. Our SAs aren't keen on this approach
> 2) Give DBAs the ability to run root.sh as the root user via sudo. This,
> of course, means that DBAs can run anything they like by editing root.sh,
> so doesn't really help. Understandably our SAs don't like this approach
>
> I am being asked to look into keeping Oracle software version specific
> root.sh scripts in a root-owned location (we are Linux only, so no
> multi-platform concerns). This would allow for secure sudo privileges. We'd
> need these for RDBMS, Grid Infrastructure, and Client.
>
> However, I've explained the scripts are dynamically generated by
> runInstaller and have the Oracle Home path hard-coded into them. We'd need
> a root-owned root.sh for every distinct ORACLE_HOME path we create (some
> hosts have multiple homes, so there's dbhome_1, dbhome_2 etc.). Maybe there
> are other considerations that I'm unaware of - I don't really like to
> second guess what else is going on in the "closed box" of the OUI that
> could be host dependent.
>
> To my mind, taking this non-standard approach is more risky than having
> someone run the script on our behalf, even if it risks introducing delays
> into the build process.
>
> How is this handled in your organisation? Have you ever been asked to have
> a centralised set of root.sh scripts under root control for this reason?
> Have you made it work?
>
> If anyone has some time to share their experiences, it would be much
> appreciated.
>
> Regards
>
> Austin
>
>
>
>
>
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
>
> NOTICE: Confidential message which may be privileged. Unauthorized
> use/disclosure prohibited. If received in error, please go to
> www.td.com/legal for instructions.
> AVIS : Message confidentiel dont le contenu peut être privilégié.
> Utilisation/divulgation interdites sans permission. Si reçu par erreur,
> prière d'aller au www.td.com/francais/avis_juridique pour des
> instructions.
>
--
Niall Litchfield
Oracle DBA
http://www.orawin.info
Other related posts:
