RE: DBAs running root.sh
Date: Tue, 4 Feb 2014 15:54:58 +0000
Message-ID: <EC65ECF8123FEE4D8FC5B212637C30400166578CCACE_at_EXCH1.morrisonsplc.co.uk>
That effectively is what the Oracle Database Vault tool does
-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Mark W. Farnham
Sent: 04 February 2014 14:59
To: hacketta_57_at_me.com; 'oracle-l digest users'
Subject: RE: DBAs running root.sh
The old solution from Burlington Coat was based on a password envelope in the operations safe. In a lights out shop I'm not sure how to do this.
- A DBA (or anyone really) on the temporary root list calls operations.
- Ops opens the safe, verifies the identity of the caller, opens that person's password envelope and give them the sudo root password for the system(s) needed.
- Op notes to SA group systems given
- Temporary rooter logs everything done (script if possible), notifies SA group when done
- SA group creates new password envelope (with new passwords, having changed them) for the ops safe, reviews what was done, gives feedback to DBA (could be as little as "seems right and necessary, thanks for letting me sleep")
Rinse and repeat as needed. This has the nice effect that if an SA is around, you can check with them if they can do what you need RIGHT NOW, so you can skip the overhead of changing all the sudo passwords. This helps create a businesslike and mutually helpful relationship amongst SAs and DBAs (which may be its best feature).
If memory serves this process was developed by Mike Prince, Gerry Claggett, Brad Friedman, and yours truly.
mwf
-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of Austin Hackett
Sent: Monday, February 03, 2014 12:08 PM
To: oracle-l digest users
Subject: DBAs running root.sh
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:
- 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
- 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
--
http://www.freelists.org/webpage/oracle-l
--
http://www.freelists.org/webpage/oracle-l
Wm Morrison Supermarkets Plc is registered in England with number 358949. The registered office of the company is situated at Gain Lane, Bradford, West Yorkshire BD3 7DL. This email and any attachments are intended for the addressee(s) only and may be confidential.
If you are not the intended recipient, please inform the sender by replying to the email that you have received in error and then destroy the email. If you are not the intended recipient, you must not use, disclose, copy or rely on the email or its attachments in any way.
This email does not constitute a contract in writing for the purposes of the Law of Property (Miscellaneous Provisions) Act 1989.
Our Standard Terms and Conditions of Purchase, as may be amended from time to time, apply to any contract that we enter into. The current version of our Standard Terms and Conditions of Purchase is available at: http://www.morrisons.co.uk/gscop
Although we have taken steps to ensure the email and its attachments are virus-free, we cannot guarantee this or accept any responsibility, and it is the responsibility of recipients to carry out their own virus checks.
--
http://www.freelists.org/webpage/oracle-l Received on Tue Feb 04 2014 - 16:54:58 CET