The use of sudoedit command question

slouching · 01-28-2010, 03:44 PM

Hi all, new to the forums and look forward to working with you all.

Have a question regarding the sudoedit command and best practices. I noticed that giving a user sudo rights to run vi is generally a bad thing as said user could break out of vi into a root shell. (ugly indeed). Thought sudoedit was my answer, but noticed that has it's own potential issues. If I specify the full path to sudoedit it does not work, I just get "Sorry, user xxx is not allowed to execute 'sudoedit /etc/hosts' as root on <servername>" Also, if I use sudo <path to sudoedit> <path to file to edit> it fails as well. If I simply specify sudoedit (with no path)in the sudoers file, it allows user to edit the file, cannot break out to root shell, but it does not prevent the user from creating a script in his HomeDir called sudoedit, and running it, through sudo, as root. (and putting something like /bin/su - in the file called "sudoedit") Anyone have any ideas to get around this? Is it just the ver of sudo? currently running sudo-1.6.9p17-3.

Thanks

GlennsPref · 01-28-2010, 07:04 PM

Hi, Welcome to LQ!

LQ has a fantastic search function that may save you time waiting for an answer to a popular question.

With over 3 million posts to search it's possible the answer has been given.

I attack this from a different direction, I think.

To be fair, This is a single user machine, with just glenn and root logins.

But when I set up the /etc/sudoers file as root (su -p), I Uncomment the wheel lines...

/etc/sudoers

Code:

# sudoers file.
#
# This file MUST be edited with the 'visudo' command as root.
# Failure to use 'visudo' may result in syntax or file permission errors
# that prevent sudo from running.
#
# See the sudoers man page for the details on how to write a sudoers file.
#

# Host alias specification

# User alias specification

# Cmnd alias specification

# Defaults specification

# Runas alias specification

# User privilege specification
root	ALL=(ALL) ALL

# Uncomment to allow people in group wheel to run all commands
%wheel	ALL=(ALL) ALL

# Same thing without a password
%wheel	ALL=(ALL) NOPASSWD: ALL

# Samples
%users  ALL=/sbin/mount /cdrom,/sbin/umount /cdrom
%users  localhost=/sbin/shutdown -h now

once this is saved, I add myself (glenn) to the wheel group. (or vis-a-vis)

Restart the system, and I now have root access with sudo,

But as far as I am aware, nobody but root and the wheel group can access any system files. Unless they know the root password.

Please correct me if I missed something.

Regards Glenn

neonsignal · 01-28-2010, 07:33 PM

The string 'sudoedit' is supposed to be treated as a special case, so you don't provide the path.

Code:

slouching ALL=NOPASSWD: sudoedit /etc/network/interfaces

Of course is important to scope which files the user is allowed to sudoedit. Letting them sudoedit any file is tantamount to giving full root access.

However, there does seem to be a hole as you point out, because the line can also be interpreted as allowing any file called sudoedit to be run as root...

GlennsPref · 01-28-2010, 08:03 PM

I guess my setup means that if my user account is breached, it's wide open.

I'm going to have to rethink my approach, ease of access is not everything.

I also use msec to keep close watch on file permissions and changes.

So far, so good.

I don't access my system remotely, maybe that's my saviour.

cheers, Glenn

slouching · 01-29-2010, 04:14 PM

Thanks for the feedback.

@Glenn. Yeah I don't want to give "wheel" as that will give the user root. I wanted to use sudoedit as an alternative to giving the users sudo to the vi command. If the user runs vi as root (through sudo) he can break out of vi to root's shell. (i.e. by using :sh in vi) so when sudoedit is used and the user tries to break out to a shell, it reverts back to their account.

@neo. Yes I agree that a path should be specified to the actual file you want the user to use sudoedit on as it would open up all the files for them to edit. (bad indeed as they could technically use sudoedit on the /etc/sudoers file). But even with a <path to file to edit> defined it was not immune to the creation of a file called sudoedit and running it through sudo. see below.

OK, so even with the specification of a path after the sudoedit command i could run sudoedit, with sudo and have it run my new "sudoedit" script and simply put /bun/su - in it:

slouching ALL = sudoedit /etc/hosts

that worked and would not allow me to break out to a root shell. However when I created my one "sudoedit" I could run it through sudo and become root:

sudo ./sudoedit /etc/hosts

So within my new sudoedit file in my home dir it basically just echoed "test" and then ran /bin/su -. This made me root on the box.

What i determined was that version I was using had this issue (sudo-1.6.9p17-3 also tested on 1.6.9p17-5) but when a colleague of mine tested an earlier version (sudo-1.6.8p12-12.el5) it worked as advertised. When he attempted to run sudo ./sudoedit (again my sudoedit script that would su to root) With this earlier version, however it did not let him run my "sudoedit" and instead printed usage message:

usage: sudoedit [-HPSb] [-p prompt] [-u username|#uid] file [...]

So it looks like the newer version of sudo I had running has a nasty sudoedit issue.

Thanks

neonsignal · 01-29-2010, 06:27 PM

Quote:

so even with the specification of a path after the sudoedit command i could run sudoedit, with sudo and have it run my new "sudoedit" script

Yes, I had tried this already yesterday and submitted a bug report. If I hear nothing from upstream, I will submit a bug report to Debian, since they are using 1.6.9 in the stable distro. Thanks.

==EDIT==
Have submitted the same bug report to Debian.

neonsignal · 02-23-2010, 07:30 PM

The problem has been fixed in the new stable version 1.7.2p4 of sudoedit.

-- edit --

Patches have also been propagated through Debian, RedHat, and Ubuntu.