Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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.
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...
# 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
%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.
Last edited by GlennsPref; 01-28-2010 at 07:05 PM.
Reason: Unless they know the root password
@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: