I shouldn't use sudo nano

Dugite-Code — Mon, 26 Jul 2021 16:00:00 GMT

Over on /r/linux a user going by /u/AlternOSx posted a short You should Know: YSK : Do not use 'sudo vim/nano/emacs..' to edit a file. Instead, set your $EDITOR and use sudoedit or sudo -e.

Long story short sudoedit copies the file you want to edit to /tmp/file.xxx and then opens it with an unprivileged instance of your editor of choice. It then overwrites the source file when you are finished editing, protecting from accidental privilege escalation of commands through your text editor.

Knowing this I came up with a quick way to enforce this best practice by added this function into my .bashrc file. Hopefully I can retrain myself not to use sudo nano all the time.

# Define the default editor in this case nano.
EDITOR=nano

# Catch calls to sudo.
function sudo() {
  if [[ $1 == "$EDITOR" ]]; then
    # The editor has been called

    if [ -w "$2" ]; then
      # If the file is writable by the current user just use the editor as normal.

      command $EDITOR "$2"
    else
      # The file is not writable use sudoedit.
      command sudoedit "$2"
    fi
  else
    # Use sudo as normal.
    command /usr/bin/sudo "$@"
  fi
}

TOTP with sudo (Google Auth)

Dugite-Code — Tue, 09 Jun 2020 16:00:00 GMT

I was reading the posts over on lobste.rs and saw this post: Is sudo almost useless?. Typically I see sudo as a safety belt to protect you from doing something stupid with administrator privileges rather than a security shield. But that doesn't mean it can't be both

As with ssh, outlined in my previous post TOTP with SSH (Google Auth), you can certainly boost your sudo usefulness security wise by throwing 2FA via google-authenticator-libpam on top of it.

Install google-authenticator-libpam

On debian/ubuntu:

    sudo apt update && sudo apt install google-authenticator-libpam

Set-up your secret keys

We now need to create the secret key, this should not be kept in the user folder, after all what is the point of 2FA if the user we are authenticating can just read the secret files. In my case I keep them in the root dir

Replace the variable ${USER} if/when you create a key for a user other than the active one.

sudo google-authenticator -s /root/.sudo_totp/${USER}/.google_authenticator
sudo chmod 600 -R /root/.sudo_totp/

You will see a QR code/secret key that you can scan with a TOTP app like andotp, authy, google authenticator or in my case I added it to my yubikey. There are also your emergency scratch codes that you should record somewhere safe.

Enable in PAM

You now need to let PAM know it should be checking the codes. There are two ways to do this, Mandatory and Only if secret key exists. I have it as Mandatory any user using sudo MUST have a secret key

In /etc/pam.d/sudo add the following configuration lines to the end of the file.

# Use Google Auth -- Mandatory
auth required pam_google_authenticator.so secret=/root/.sudo_totp/${USER}/.google_authenticator user=root

# Use Google Auth -- Only if secret key exists
# auth required pam_google_authenticator.so secret=/root/.sudo_totp/${USER}/.google_authenticator user=root nullok

Bonus do this for su as well

You can do the same thing for su as well however obviously the user variable will be root rather than the user attempting to elevate their privilege's.

Setup the key as before, just for the root user

sudo google-authenticator -s /root/.google_authenticator
sudo chmod 600 -R /root/.google_authenticator

In /etc/pam.d/su add the following configuration lines to the end of the file.