The usual reason to implement sudo is that there is a requirement to have a reliable record of who-did-what for privileged accounts. In those cases, "looks like root did it" is not going to be an acceptable answer: the expected answer is more like "This log proves beyond reasonable doubt that at 14:30 yesterday, Joe Bloggs the junior sysadmin used his root privileges to make this change."
The problem of "sudo su -" is mostly related to logging, and it is three-fold:
1.)
When a user is allowed to run a shell as root, only the fact that a shell is started is logged - not the commands entered within the shell.
One possible solution is to forbid running a shell through sudo. The solution is not ergonomically optimal, and may be hated by sysadmins; but although sysadmins may not like it, they can live with it if necessary.
Using the shell's history file as a log is not a good solution: the history file is not designed as a secure log. It must be writeable by the user whose actions it records, so the user can always overwrite it to hide his/her actions.
Alternative solutions are to use the audit logging functionality of the OS, or a session recorder like sudosh/rootsh. For root access, these should be paired with some mechanism that transmits the log events to another secure system, because root can typically undo or side-step any purely local security measures.
2.)
"sudo su -" in particularly troublesome, because it causes two log lines to be recorded.
The first log line will be written by sudo, and it tells that the user executed sudo to run the command "su -" as expected. The second line will be recorded by su, and in some OS versions it will tell you that it was invoked by root to become root. That is not very useful. If two users do it simultaneously enough, the log lines will get entwined together and it will be hard to track which line belongs to which session. Granted, you can usually use the TTY field in both sudo's and su's messages to sort it out - but if the commands are run in a context that has no TTY (e.g. cron jobs), your log might be ambiguous. For legally-mandated audit requirements, this is a bad thing.
For most practical purposes, "sudo -H -i" does exactly the same thing as "sudo su -": the only significant difference is the four $SUDO_* variables sudo adds to the environment to indicate sudo was used. But it has the added property of producing one clear and easily processible log line telling exactly what was done. If you're implementing something like HIDS to automatically screen your log files for signs of intrusion, this makes the log analysis rules easier to write.
If you set "Defaults set_home" in sudoers, you can shorten the command to "sudo -i", so you don't even have the excuse of "But it's easier to type sudo su -".
3.)
When a system is configured to run applications using dedicated application accounts rather than the root account, the requirement to access those specific accounts will usually be more common than the need to do thing using the root account. Commonly, this is done using a command like "sudo su - appuser".
In my opinion, "sudo su - appuser" indicates persistent refusal to learn new things. To allow this, you need to grant the user root access for the purpose of running "su - appuser" as root:
joeuser ALL=(root) su - appuser
This is excessive, for sudo could do the entire job in one step, using this syntax:
sudo -H -u appuser -i
If the latter sudo syntax is used, the sudoers file line can be more straightforward to understand:
joeuser ALL=(appuser) ALL
The auditor needs only take one look at it to see "Joe User is authorized to run commands as appuser, but has no root access."
If "sudo -H -u appuser -i" is too long to type, shell aliases or scripts can easily remedy that.
MK
MK
MK
