Sudo And It's Intended Purpose
Sudo And It's Intended Purpose
I've seen many threads on LQ regarding the use of 'sudo' and each time I'm shocked at how often this utility is misunderstood.
Here I will will try and convey my interpretation of its intended proper use and describe alternate methods of accomplishing the same tasks more securely or in a best use context.
'sudo' is a utility that grants authority to run very specific commands as root from a non-root account, or specifically, a person who should never have access to the root account or password.
Administrator's Abuse Of 'sudo'
The most severe abuse of 'sudo' I see comes from System Administrators by using it as an alternative to logging in as root. Many System Administrators configure 'sudo' in such a way that can run *any* command including shells, or otherwise, open-ended commands that allow user input as parameters - and usually without the need to fulfill a password challenge. While there is nothing syntactically wrong with doing this, it is an ignorant method of System Administration and decreases the ability of established auditing tools to keep track of who is doing what to the system.
A good rule of thumb for System Administrators to follow is that 'sudo' should not be used by anyone with knowledge of the root password. If you have access to the root account, you should use it with 'su -' or 'su -c <command>'. 'su -' is suggested if you have numerous tasks to do, while 'su -c <command>' is suggested if you just need to execute one or two commands as root.
Non-root Users And 'sudo'
Now that we've got people with knowledge of the root password out of the way, lets talk about non-root users...
As I mentioned before, 'sudo' was designed for non-root users to run *very specific* commands. System Administrators should never allow sudo users access to open-ended commands (such as shells), or allow user-specified parameters to commands. Unforeseen security holes can be exploited when a System Administrator doesn't consider all the implications of running a program as root.
For example, does the program allow a user to shell out to something open-ended such as vi does? Perhaps the program allows you to create files with a user specified file mask such as snort? If the System Administrator takes care to specify exact commands for non-root users to execute, the system will remain secure while those semi-trusted users are allowed to perform root related tasks.
Another protection that 'sudo' affords us is the ability to force a non-root user to re-authenticate before a specific command can be run as root. A non-root user is more likely to not understand the security implications of locking their terminal while away from keyboard. Requiring re-authentication is a safeguard for System Administrators to ensure the entrusted commands are not abused by unauthorized users.
I've seen many threads on LQ regarding the use of 'sudo' and each time I'm shocked at how often this utility is misunderstood.
Here I will will try and convey my interpretation of its intended proper use and describe alternate methods of accomplishing the same tasks more securely or in a best use context.
'sudo' is a utility that grants authority to run very specific commands as root from a non-root account, or specifically, a person who should never have access to the root account or password.
Administrator's Abuse Of 'sudo'
The most severe abuse of 'sudo' I see comes from System Administrators by using it as an alternative to logging in as root. Many System Administrators configure 'sudo' in such a way that can run *any* command including shells, or otherwise, open-ended commands that allow user input as parameters - and usually without the need to fulfill a password challenge. While there is nothing syntactically wrong with doing this, it is an ignorant method of System Administration and decreases the ability of established auditing tools to keep track of who is doing what to the system.
A good rule of thumb for System Administrators to follow is that 'sudo' should not be used by anyone with knowledge of the root password. If you have access to the root account, you should use it with 'su -' or 'su -c <command>'. 'su -' is suggested if you have numerous tasks to do, while 'su -c <command>' is suggested if you just need to execute one or two commands as root.
Non-root Users And 'sudo'
Now that we've got people with knowledge of the root password out of the way, lets talk about non-root users...
As I mentioned before, 'sudo' was designed for non-root users to run *very specific* commands. System Administrators should never allow sudo users access to open-ended commands (such as shells), or allow user-specified parameters to commands. Unforeseen security holes can be exploited when a System Administrator doesn't consider all the implications of running a program as root.
For example, does the program allow a user to shell out to something open-ended such as vi does? Perhaps the program allows you to create files with a user specified file mask such as snort? If the System Administrator takes care to specify exact commands for non-root users to execute, the system will remain secure while those semi-trusted users are allowed to perform root related tasks.
Another protection that 'sudo' affords us is the ability to force a non-root user to re-authenticate before a specific command can be run as root. A non-root user is more likely to not understand the security implications of locking their terminal while away from keyboard. Requiring re-authentication is a safeguard for System Administrators to ensure the entrusted commands are not abused by unauthorized users.
Total Comments 0
