If you have ever launched a Linux instance on Amazon EC2 and SSH’d to it you have probably attempted to use sudo to perform tasks which required elevated permissions. I definitely have and if you are like me as well, you ran visudo (or inspected the /etc/sudoers file) on one of these servers at least once expecting to see the account you were SSH’d with listed there right? Well you may have been a bit puzzled not to see it there. I definitely was for a few moments until I realized that Amazon uses a certain feature of the sudoers file to make sudo possible for the account.
Ordinarily, after running ‘visudo’ we would be presented with an editable version of the /etc/sudoers file that would permit us to modify which accounts can be allowed to run sudo, and which commands those accounts can subsequently run.
Basic Sudoers File Example
# User privilege specification
root ALL=(ALL:ALL) ALL
# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL
# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL
# See sudoers(5) for more information on "#include" directives:
Essentially, we see that members of the admin and sudo groups have sudo privileges as well as the root account. None of these apply to the EC2 Linux account an AWS user would use however look at the last line. That #includedir directive is what makes it possible. Please note that the # in this line is not a comment. Confusing but true. It is a directive that tells the sudoers file to look in the /etc/sudoers.d directory for other files to parse for the sudoers configuration.
“But Wait! What do the ALLs Mean?”
Starting from left to right:
In a scenario where a single sudoers file might be used across many hosts, this ALL specifies which hosts these sudo rules apply to. In this case, no host restriction is included
Specifies the users the user can run commands as
This all specifies the groups the user can run commands as
This final ALL indicates the commands the user is permitted to run
Please note that there is great flexibility in the configuration of sudo privileges whereby specific commands, users, groups, etc. can be listed as well as other cool things. Run “man sudo” at your shell prompt to learn more.
If we navigate to /etc/sudoers.d on an EC2 instance, we can see a file listed there. In most cases it might start with a high number such as 90. These files are parsed in numerical order. If you include your own files, you should keep this in mind as a file begining with a single digit ie. 1-my-new-sudofile will be parsed after a file named 10-my-new-sudofile. Here is an example of one of these supplemental sudo files:
Supplemental Sudo file example // Follows same formatting rules as /etc/sudoers
# User rules for adminubuntu
adminubuntu ALL=(ALL) NOPASSWD:ALL
In this example, a user named adminubuntu is granted the ability to run ALL commands with no password on ALL hosts as any user. If adminubuntu were to run “sudo -l” at the shell prompt, they would see their effective privileges, granted from the files found under /etc/sudoers.d and the /etc/sudoers file itself.
Edit: If you ever need to modify the sudo files found under /etc/sudoers.d you can run the following command:
visudo -f /etc/sudoers.d/[FILENAME]
So why would someone want to do things this way you might ask? Well one reason is that it prevents Administrators from modifying the /etc/sudoers file directly. This may be ideal from a security and operations stability perspective. The /etc/sudoers file is sensitive to formatting errors and will not advise an administrator if there are syntax or formatting issues before saving. For this reason, visudo is preferred as the editing mechanism for this file as it leverages lock checking as well as error checking. Well, hope this helps explain sudo a bit better on AWS. Happy sudo’ing on your AWS box!