mfillpot wrote:

I differ in my opinion, sudo represents a potential issue by allowing attackers to potentially access root rights from a standard user account, which may have a weak password. I think it is better practice to keep the root account, remove sudo rights except for specific actions and secure root with a difficult password. As for ssh that should be restricted to not allow root login and limit retries or only allow root ssh access via a key file.

sudo sux

I personally use both su and sudo, but for different tasks.

Sure, they overlap in many ways; sudo -s can give you a root shell (like su), and su -c lets you run a single command as root (like sudo). Sudo can also be configured to request the root password instead of the user password (check man sudoers). As pointed out in previous posts, a properly configured system can be about equally secure with both approaches.

What I like about sudo though, is that the flexibility you get through the /etc/sudoers file. For instance, this entry is taken from my sudoers file:

jabirali hermes=NOPASSWD: /usr/bin/acpitool -s

That line lets the user jabirali from the host hermes (the local hostname) run the command /usr/bin/acpitool -s (suspend the computer) with root privileges - without entering a password. If the alternative is e.g. giving SUID-rights to /usr/bin/acpitool, this approach has many advantages:
[ul][li]You can restrict what arguments are passed to the program; invoking acpitool in any other way than the exact wording specified in /etc/sudoers will not work.[/li][li]One application with SUID-rights (sudo) is likely more secure than a lot of SUID-apps scattered throughout your filesystem.[/li][li]You can give certain users (e.g. a special group) rights to execute a handful of commands, without either giving them the root-password or modifying the rights of the files.[/li][li]One file is easier to manage in the long run (in my opinion) than scattered SUID rights.[/li][/ul]
Another potentially useful example could be to give a certain user the ability to su to another user by providing his own password, this time from all hosts:

jabirali ALL=/bin/su guest

(This allows jabirali to run /bin/su guest as root after providing his own password)

If you still want to use only su to run anything but selected tasks (like the examples above), that should also be easy to configure. E.g. the default /etc/sudoers on ArchLinux contained this line:

%wheel ALL=(ALL) ALL

That gives everyone in the group wheel permissions to run anything as root, given that they provide their own password. You can just comment out that line! Or perhaps more useful: modify it to require the root password (search for rootpw in the sudoers manpage).

All this sudo staff is fantastic but I'll stay with my opinion: admin staff should be done by the admin and not by any user.

I guess it's about choice, isn't it? ;)

Regards

I completely agree with you.

I think I am going to give Debian a try!