Rik van Riel wrote:
On Sat, 3 Nov 2007 18:22:16 -0500 (CDT)
"Chris St. Pierre" <stpierre@xxxxxxxxxxxxxxxx> wrote:
On Sat, 3 Nov 2007, Carville, Stephen wrote:
Do not give it all then try to deny certain commands. Any reasonably smart use
can defeat that. Start with nothing and allow only what is necessary.
This is _excellent_ advice.
Let's say you give someone sudo but don't allow them to run 'su'. I
can think of half a dozen ways off the top of my head to get around
that:
'sudo bash'; run su
'sudo screen'; run su
'sudo emacs'; M-x shell; run su
'sudo script su'
Write a shell script that invokes su and run it with sudo
'true | sudo xargs su'
That was after about 30 seconds of thought. A dedicated attacker
could find significantly more avenues of attack.
less, vi and a number of other innocent looking programs
can be used to invoke a shell.
Of course, if you can sudo vi, you could just edit the
sudoers file.
Stephen's advice is to be taken seriously.
Of course, there *are* limits to what you can control, unless, as I originally
said, you gave them a laundry list of what commands they *can* execute.
For example, at work, in production, I edit httpd.conf or ssl.conf, and have
the production admin turn down apache, copy the files over, then turn it back
up. It gets copied by root, and so that's the owner, which is just what it
needs to be....
mark
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
