RE: DBAs running root.sh
- From: Michael Schmitt <mschmitt@xxxxxxxxxxxx>
- To: ORACLE-L <oracle-l@xxxxxxxxxxxxx>
- Date: Mon, 17 Feb 2014 20:46:58 +0000
I am not sure if this was already mentioned, but one of my co-workers had what
I thought was a good idea to allow the DBA team to run this in our environment.
We are going to setup a sudo script that performs a checksum on the root.sh to
confirm it hasn't been altered before it executes as root. We utilize a pretty
standard naming standard for the ORACLE_HOME directory, so should work well for
us
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Herring, David
Sent: Tuesday, February 11, 2014 5:07 PM
To: lcarapinha@xxxxxxxxx; stojan.veselinovski@xxxxxxxxx
Cc: hacketta_57@xxxxxx; ORACLE-L
Subject: RE: DBAs running root.sh
Well, having access to run anything as "root" is a huge hole, especially if you
can connect directly to a shared account since it's that much harder to track
down who ran it. Who is to say that instead of running "root.sh" you instead
do "rm root.sh; ln -s <some scary script> root.sh" first? Now "root.sh" is
really a link to something else and you've got full "root" for it. Just an
example of what others have referred to in this thread in more general ways.
Why would we do the above? Besides as a way to get around not having access to
run "root.sh" (using other "sudo"-granted access) we wouldn't. But auditors
don't care and if that hole causes an audit failure it could scare away
clients, whether justified or not. I guess we have to trust sysadmin more than
DBAs.
Dave Herring
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Luis
Sent: Tuesday, February 11, 2014 12:08 PM
To: stojan.veselinovski@xxxxxxxxx
Cc: hacketta_57@xxxxxx; ORACLE-L
Subject: Re: DBAs running root.sh
This is really an interesting topic, still one thing comes to my mind. We, as
DBA, use our sysdba "power" (or other privileged accounts) to handle, the most
valuable asset in an organization: Data. That is what really matter. Why do we
need "advanced restrictive policies" to execute a script that finishes an
Oracle installation when we have a privileged account in the database? Just
imagine the damage you can do without any access to a unix shell..
Role separation is ok to me, but sometimes people focus much on it and
bureaucracy wins.
Luís
http://lcmarques.com
On Wed, Feb 5, 2014 at 10:08 AM, Stojan Veselinovski
<stojan.veselinovski@xxxxxxxxx> wrote:
Its an interesting topic and I've had countless hours of discussion with
sysadmins about DB servers being managed and run by DBA's.
If we wanted to do serious damage we could., regardless of any root account.
Any compromise like having sudo to commands is only a step away from kicking
out to a root shell and away you go.
With the GI stack needing elevated privileges and for most shops its managed
and run by DBA's it really does become a bit of a road block.
Patching GI, troubleshooting processes, strace, truss, etc, etc.
Not sure if there is a perfect answer but in my current place we have sudo to
commands and root in "some" places and a good relationship with the sysadmins
Stojan http://www.stojanveselinovski.com/blog
--
Cumprimentos,
Luís Marques
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
