Common Sudoers File Mistakes And How To Avoid Them

Misconfiguring the Sudoers File

The sudoers file controls who can run what commands as sudo on a Linux system. It is located at /etc/sudoers by default and should only be edited using the visudo command. Misconfiguring the sudoers file can lead to security issues or prevent access, so understanding common mistakes can help avoid problems.

Explaining the sudoers file and its purpose

The sudoers file uses a specific syntax to configure sudo privileges. It allows declaring which users or groups can run sudo, which commands they can run, and on which hosts. The key purpose is to provide granular control over elevated privileges on a Linux system.

Some key components of the sudoers file include:

User and group aliases – collections of users or groups to apply rules to.
Host aliases – collections of hostnames to match against.
Command aliases – groups of commands.
NOPASSWD – allow sudo without a password prompt.
Defaults – default settings sudo inherited by users.

Used properly, the sudoers file is a powerful tool to implement the principle of least privilege by granting only necessary privileges to users. However, mistakes can weaken security or make the system unusable to privileged users.

Common mistakes

Forgetting the syntax

The sudoers file has its own syntax that allows fine-grained control over privileges. However, forgetting or misusing the syntax is a common source of mistakes. Examples include:

Forgetting commas between user names
Mismatched curly braces around host names
Incorrect capitalization of directives like NOPASSWD

These types of syntax errors can lead to sudo failing to parse the sudoers file and disabling all sudo access. Using visudo mitigates this by catching errors during edit time.

Allowing too much access

It is common to allow more access than intended when granting sudo privileges. For example:

Allowing a broader group like all developers to sudo instead of individual users
Using wildcards like ALL=(ALL) ALL instead of specific commands
Specifying a broad host alias match like ALL

These mistakes weaken security by allowing more people to run more commands with elevated privilege than necessary. Always aim to follow the principle of least privilege.

Preventing access unintentionally

It is also common to accidentally remove access when modifying the sudoers files by mistakes like:

Misspelling a user name
Commenting out a rule that is still needed
Setting a more restrictive host alias than intended

These types of errors can lock out legitimate sudo users unexpectedly. Changes should always be tested before implementing globally.

Best practices

Following best practices can help avoid some common mistakes:

Using visudo for editing

The visudo command provides the following benefits:

Catches syntax errors during edit time
Prevents multiple users editing at once
Locks the file and checkpoints changes

This helps catch mistakes early and prevents race conditions around editing.

Testing changes before implementing

Before rolling out sudo changes globally:

Test rule changes in a non-production environment first
Have a rollback plan ready in case of unintended lockout
Consider time-based rules like run a rule for 1 hour then expire

Testing minimizes business impact of any mistakes.

Using groups and aliases

Leveraging user groups and aliases makes management easier by allowing you to:

Add/remove individual users from groups instead of editing the sudoers file directly
Make a single change to an aliased collection of entities rather than individually

This reduces editing frequency and chances for error.

Restricting access with host restrictions

Limiting what hosts a user can sudo from can reduce risks by:

Preventing access from unknown hosts
Containing impact if a server is compromised

Host aliases provide a simple way to restrict sudo to known trusted hosts.

Example configurations

Some common examples help illustrate typical sudoers file use cases.

Allowing users sudo access

To allow the developers group sudo access:

# Allow developers group sudo access
%developers ALL=(ALL) ALL

To allow jsmith full sudo access without a password prompt:

# Allow jsmith full sudo access without password
jsmith ALL=(ALL) NOPASSWD: ALL

Restricting commands

To allow only sudo reboot and sudo shutdown:

# Allow only reboot and shutdown 
%operators ALL=/sbin/reboot, /sbin/shutdown

Host aliases

To allow access only from known app servers:

# Host alias for app servers 
Host_Alias APP_SERVERS=appsrv01.company.com,appsrv02.company.com

# Allow developer sudo access from app servers only  
%developers APP_SERVERS=(ALL)ALL

Troubleshooting issues

Common issues that can occur due to sudoers misconfigurations include:

Parsing errors

Seeing errors like:

>>> /etc/sudoers: syntax error near line 20 <<<
sudo: parse error in /etc/sudoers near line 20
sudo: no valid sudoers sources found, quitting
sudo: unable to initialize policy plugin

Indicates a syntax error that needs to be fixed using visudo before sudo will work again.

Access denied unexpectedly

Having users report they now get:

user is not in the sudoers file. This incident will be reported.

When trying to sudo indicates an over-restrictive change was likely made unintentionally.

Debugging techniques

Troubleshooting tips include:

Check /var/log/auth.log for additional sudo messages
Add log_output or syslog=authpriv flags to get more verbose output
Use the sudo -l command to test rules
Consult documentation on sudoers options

Carefully go through recent changes line by line to find any errors.

Securing the sudoers file

Some steps to secure the sudoers file include:

File permissions

Set the sudoers file ownership and permissions to root read/write only:

chown root:root /etc/sudoers
chmod 0440 /etc/sudoers

This prevents non-root users from accessing or modifying sudo rules.

Audit logging

Enable audit logging via:

 
Defaults syslog=authpriv 
Defaults log_output

This will log sudo usage and errors to /var/log/auth.log allowing monitoring for misuse.