Linux Upskill Challenge – Part 03

Time to complete: ~1-1.5 hours

Working with Sudo, The /etc/shadow File, Hostname Change, TimeZone Settings

Let’s start at the top: what is sudo? You may have heard of it, you may not have, but it is an integral part to being a Linux administrator. Sudo is a program that allows a user to run other programs/commands as another user, usually the root user. This is authenticated with the credentials of the user you are running as. So, what does this afford us? Why not just log in as the root user and do your bidding straight from the root account? Well, there’s a few reasons why using sudo is beneficial:

  • You aren’t giving out your root password to other admins and users.
  • On systems where sudo is being utilized the root user itself can be disabled, heightening security.
  • There is an audit trail of all sudo activity in the form of logs.
  • You can limit users to have access to certain programs using sudo, further restraining privileges in the interest of security.
  • The process of running a sudo command offers a little buffer that promotes “think before you leap”.
  • Sudo authentication expires automatically, requiring the input of the user password again. Leaving a machine unattended (!!!) is less of a risk than if the root user was left logged in.

So how does this work? How do I use sudo? It’s simple. Just type sudo before the command you wish to run as root in terminal, enter your account password (your password, not the root password), and the command will be executed with root privileges. Easy to use? You bet.

But what’s really going on? Well, if we take a look at the sudo binary we’ll notice something a little peculiar about the permissions. Use the which command to see where sudo actually lives, then use ls -l to check permissions.

|dpaluszek@upskill:~ -bash v5.0==>which sudo
|dpaluszek@upskill:~ -bash v5.0==>ls -l /usr/bin/sudo
-rwsr-xr-x 1 root root 166056 Jul 15 00:17 /usr/bin/sudo

In the permissions for the sudo binary, notice the “s” in the fourth column? This SetUID bit means that instead of the binary being invoked by the user it will be executed as the user who owns the binary, in this case, root.

So what sudo does is check the sudoers file /etc/sudoers and sees if the user who invoked sudo is on the party list. If so, and the credentials aren’t already cached (we’ll get to that in a moment), the invoking user will be prompted for their password. Entering this password will allow the command to execute as the root user. This password will be cached for 5 minutes (5 minutes is the default on most Linux systems) meaning that within this window you can run more sudo commands without having to enter your password. Sudo creates a child process where it changes the target user (again root) and then the command is executed.

If you were thinking that users need to be explicitly added to the sudoers file and that they weren’t on it by default you’d be right. So how do we grant access to sudo? It’s as easy as modifying the sudoers file itself by adding an entry for either the specific user or for a user group. It’s a no brainer that this needs to be done as the root user! Run sudo nano /etc/sudoers and enter your password to open the sudoers file in a the nano editor.

sudo nano /etc/sudoers

Scroll down a bit and you’ll notice there are three sections we should be concerned with here. The “User privilege specification” section is where users are listed along with what sudo permissions they have. The two sections below that govern group membership permissions to sudo, in this case the admin and sudo groups have full access. The permissions are broken down as follows:

 1    2    3   4    5
  1. The username whom is getting sudo access. Groups are prefaced with a percent sigh (%).
  2. Hosts you can run sudo commands on.
  3. The target users you are allowed to run commands as.
  4. The list of groups you can switch to using the -g switch.
  5. The commands you can run.

Here’s an example of a sudoers entry that is a bit more granular:

%localadmin desktop1,desktop2=(root) /usr/bin/rm /usr/bin/hostname

Here we specify that users in the localadmin group can run the rm and hostname commands as root on 2 machines: desktop1 and desktop2.

Let’s use sudo to play around with the file that user passwords are hashed and stored in. First let’s check the permissions. Password hashes are stored in /etc/shadow.

|dpaluszek@upskill:~ -bash v5.0==>ls -l /etc/shadow
-rw-r----- 1 root shadow 1163 Aug 19 11:55 /etc/shadow

You’ll notice root owns this file. Let’s try to see the contents of this file:

|dpaluszek@upskill:~ -bash v5.0==>cat /etc/shadow
cat: /etc/shadow: Permission denied

Oh noes. DENIED. Let’s use sudo then. You can use either of these two commands, the latter being a nifty shortcut that runs the last command run:

sudo cat /etc/shadow
sudo !!

If you take a look at the output you’ll notice a line for every user on the system. Most will be built in system accounts for services and whatnot but you should see an entry for your user. Mine looks similar to this:

|dpaluszek@upskillchallenge:~ -bash v5.0==>sudo cat /etc/shadow
[sudo] password for dpaluszek: 

Let’s break down our entry for our secondary user mmessier (Note I truncated the password hash to make this easier to read):

    1   :           2            :  3  :4:  5  :6:7:8:9

Break down this line by section (between colons, there’s a total of 9 fields) and note what each represents:

  1. Username – The username on the system.
  2. Encrypted password – This is a hash of the password prefaced with what type of encryption is being used, delimited by dollar signs. These are the little encryption codes:
    • $1$ – MD5
    • $2a$ – Blowfish
    • $2y$ – Eksblowfish
    • $5$ – SHA-256
    • $6$ – SHA-512
  3. Date of Last Password Change – The date of the last password change, expressed as the number of days since Jan 1, 1970.
  4. Minimum Password Age – The minimum password age is the number of days the user will have to wait before she will be allowed to change her password again.
  5. Maximum Password Age – The maximum password age is the number of days after which the user will have to change her password.
  6. Password Warning Period – The number of days before a password is going to expire (see the maximum password age above) during which the user should be warned.
  7. Password Inactivity Period – The number of days after a password has expired (see the maximum password age above) during which the password should still be accepted (and the user should update her password during the next login).
  8. Account Expiration Date – The date of expiration of the account, expressed as the number of days since Jan 1, 1970.
  9. Reserved Field – This field is reserved for future use.

You can see why this file is owned by the root account. It contains sensitive information that should not be readily available to regular users. Attempts to crack the hash could be perpetrated should those hashes be exposed. I would also recommend not editing this file by hand unless you really know what you are doing. It is always a better idea to manipulate the contents of thi file using commands like passwd and chage.

Moving on.

Let’s restart our machine using the reboot command:

|dpaluszek@upskill:~ -bash v5.0==>reboot
Failed to set wall message, ignoring: Interactive authentication required.
Failed to reboot system via logind: Interactive authentication required.
Failed to open initctl fifo: Permission denied
Failed to talk to init daemon.

Denied again! Looks like we’ll have to sudo this one too. Run either of these to reboot the machine:

sudo shutdown -r now
sudo reboot

Use the uptime command to verify the machine did indeed reboot.

|dpaluszek@upskill:~ -bash v5.0==>uptime
 14:04:44 up 0 min,  1 user,  load average: 0.98, 0.24, 0.08

Excellent. Reboots are healthy, after all.

The sudo command logs its actions for your review. Let’s take a look at the log file /vat/log/auth.log after running a command as root.

|dpaluszek@upskill:~ -bash v5.0==>sudo hostname
[sudo] password for dpaluszek: 

Cool. Let’s now cat the auth file and see what it shows:

sudo cat /var/log/auth.log

Notice the entry for when I ran hostname? This audit trail proves useful in the sysadmin setting. It is also useful to see what commands you have run in the past, in the event you break things.

Sep 11 14:07:19 upskill sudo: dpaluszek : TTY=pts/0 ; PWD=/home/dpaluszek ; USER=root ; COMMAND=/usr/bin/hostname

Alternatively you can just grep sudo from the file in order to just grab the information you wish to see with grep sudo /var/log/auth.log.

Now that we have a grasp on how sudo works and what it can do for us let’s move on to renaming our machine.