I tried that way too but it did not helped and more over... let me say this.. if the user copies the /usr/bin/passwd binary file to other location... he can execute that password..change...
All I am looking is in any means he should not execute the password... but he should be able to execute the rest all commands.
Looks like you have some kind of problem there. I tested this fully on my RHEL 6.2 box. It's working perfectly. Copying /usr/bin/passwd to another directory and executing does not even work in my case! What's going on in your Ubuntu box?
Here's the snippet in /etc/sudoers:
testuser ALL=(unixuser:unixuser) ALL, ! /usr/bin/passwd
Here's what I tested:
[testuser@blue ~]$ sudo -u unixuser passwd
Sorry, user testuser is not allowed to execute '/usr/bin/passwd' as unixuser on blue.
[testuser@blue ~]$ cp `which passwd` .
[testuser@blue ~]$ ls -l
total 32
-rwxr-xr-x. 1 testuser testuser 32680 Feb 25 11:51 passwd
[testuser@blue ~]$ sudo -u unixuser ./passwd
[testuser@blue ~]$ sudo -u unixuser ./passwd unixuser
Can you check /var/log/secure? Also, make sure that you are using visudo to edit /etc/sudoers file as it will show you syntax error. Recheck all of the aliases you created and make sure there's no colliding rule which permits the user to execute passwd as another.
Ok.. then instead of echo I have set up /bin/rm ... still the sudo does not work as expected.
I set alex ALL=(cbttest:sytgrp) ALL, !/bin/rm
through visudo and there was no syntax error popped out.
was able to sudo to cbttest with alex.. tried to rm a file... I was able to delete the file(in general I should not....
-i option in sudo acts similar to "su - username" or login. It changes the environment to that of the user in question. So the UID and EUID will be that of the user you are trying to sudo to (cbttest). To system it's as if cbttest has logged in and it lets you execute the passwd command. Dangerous but this is the fact!!
---------- Post updated at 02:33 PM ---------- Previous update was at 02:21 PM ----------
By the way, allowing all commands and restricting only passwd does not even get closer to secure your cbttest account. For an example, user can run "sudo -u cbttest vi" and then in vi, they can press ESC and execute "!/bin/sh" to get a shell which will run with cbttest's privileges.
My opinion is to allow execute permission on very limited commands which they really need. Restrict vi, etc. commands which can give shell escape.
---------- Post updated at 09:39 PM ---------- Previous update was at 03:07 PM ----------
Admin,
I have tried the way you want me to do.
My Sudoers file
# User privilege specification
root ALL=(ALL:ALL) ALL
alex ALL=(cbttest:sytgrp) ALL, !/bin/rm
[alex@ubuntu] "/home/alex/Desktop"
$ whoami
alex
[alex@ubuntu] "/home/alex/Desktop"
$ ls -ltr /home/cbttest/sample_file.log
-rw-rw-r-- 1 cbttest sytgrp 41 Feb 25 08:33 sample_file.log
[alex@ubuntu] "/home/alex/Desktop"
$ sudo -u cbttest rm /home/cbttest/sample_file.log
[sudo] password for alex: *******
[alex@ubuntu] "/home/alex/Desktop"
$ ls -ltr /home/cbttest/sample_file.log
ls: sample_file.log: No such file or directory
So the file got deleted... as per the sudoers file it should fail to delete... but it deleted...
Emacs, Smitty in AIX, find (you run sudo find / -name "*" -exec rm -f '{}' \; and you blow up the system), PERL (you can run external commands with "system" function from a PERL script) etc. are the commonly used programs that should never be allowed to be executed through sudo with root privileges. There are myriad number of other programs/tools which are potentially dangerous when using with sudo (root permission).
Is there a short and simple way to disable 'sudo' for connections created by 'ssh'?
Technically, I don't think you could do that. Once you get authenticated through SSH, you have all of the access you would have if you logged into the console of the machine. If that includes sudo, then you will have sudo access. Nothing can be done to block it (as far as my knowledge goes, but I could be wrong!).
what a surprise - 'visudo' tells me there is a syntax error in this line! How to enable the includes?
includedir should always be preceded by #. It's like #include <stdin.h> in a C program
Here's what a RHEL sudoers file has to say:
## Read drop-in files from /etc/sudoers.d (the # here does not mean a comment)
#includedir /etc/sudoers.d
If you need an idea about sudoers file and how to simulate RBAC with it, check my old post in this forum.
I am using a Red Hat Enterprise 5 Linux box. I find if a user is in /etc/sudoers file, then if the user run command with sudo, the user will run this command with root privilege (without knowing root password, the user runs sudo only need to input the user's own password in order to run a command with sudo). Is that correct understanding?
If yes, then is it a security hole? Since users other than root could run with root privilege?
Your understanding is correct, but this is not a security hole unless it is managed badly.
The root user decides who is added to the sudoers file, and also what commands this user can run as sudo. While often the user is given access to all commands and can sudo any of them, this does not have to be the case. It could be set up to only allow sudo access to a small number of commands or even just to one.
As the root user (administrator) has final control over who is added to the sudoers file and what permissions they are given, it is not a security hole if they're doing their job correctly.
As spynappels said, sudo does not create a security hole if /etc/sudoers is managed carefully. sudo has been used as industry standard although you have Role Based Access Control with SELinux (also RBAC in Solaris and AIX).
Just to make a point here that using sudo, not only you can delegate root privileges, but also you can do the same for any user account.
