Sudo & su

mark m.roth2006 at rcn.com
Sun Nov 4 16:09:02 UTC 2007


Rik van Riel wrote:
> On Sat, 3 Nov 2007 18:22:16 -0500 (CDT)
> "Chris St. Pierre" <stpierre at NebrWesleyan.edu> 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




More information about the redhat-list mailing list