Re: DBAs running root.sh
- From: Matthew Zito <matt@xxxxxxxxxxxxxxxxx>
- To: christopherdtaylor1994@xxxxxxxxx
- Date: Mon, 3 Feb 2014 13:01:49 -0500
Wait - I forgot about one option that I alluded to in the first paragraph
of my email - commercial sudo replacements that offer more advanced
capabilities where they actually intercept systems calls to try to
anticipate what users are (negatively) trying to do. They're expensive,
complicated to run well, and usually people can figure out how to get
around them. But they get used from time to time, especially at really big
companies.
One or two big companies I deal with have an intermediary solution, where
they can "break glass" to get access to root for things like root.sh, but
they have to go to a website, open a ticket with what they're doing, it
gets approved, adn they get the root password, which is actually
automatically generated. Tehy then log in with that password once, run
root.sh, and then the password is changed automatically until the next
person requests root access.
Again, complicated and expensive.
Matt
On Mon, Feb 3, 2014 at 12:45 PM, Matthew Zito <matt@xxxxxxxxxxxxxxxxx>wrote:
> Unfortunately, no, sudo cannot do this, though there are commercial tools
> that can. The issue is that when sudo runs a shell script, it's opaque to
> the sudo command - sudo just spins up a subshell and execs the script, and
> from there it doesn't care.
>
> The way I've seen organizations deal with this:
>
> - admit the fact that since the only thing that really matters on database
> servers is the database, they let DBAs have sudo access to root entirely
> - they have sysadmins run root.sh, which stinks for everyone, especially
> on RAC. They also choose not to think about the fact that any DBA could
> have changed the root.sh script to do something malicious, as they never
> check
> - they have DBAs have sudo access to root.sh, and pretend not to notice
> that means that gives DBAs the keys to the kingdom
> - They use a product that automates the installation of database
> environments that runs the root.sh for them in a controlled environment and
> prevents users from maliciously doing things as root (disclosure: I made
> one of those products, so I have a certain bias)
>
> There's no ideal solution - you pay a penalty in security, governance,
> time/complexity, and/or cost.
>
> Matt
>
>
Other related posts:
