Little Brother

In Unix and Linux, best practices call for a strict segregation in the assignment of rights between daily work and administrative tasks. Administrative chores were once reserved for the superuser account. If you are logged in as the superuser, which is normally named root, you are allowed to do everything up to deleting the entire system.

Admins at New York University developed Sudo back in 1980 to prevent students from getting unneeded privileges. The name Sudo stands for "Superuser Do." It lets you give privileges to a user who is a member of the sudo group for limited time or for a specific task. To do this, prepend sudo to a command whose execution requires these privileges. Then enter your user password to authorize it.

Sudo became more fashionable in Linux after it was adopted by Ubuntu, and it is now a standard feature of most distributions. Sudo sounds simple on the surface, but it is actually highly evolved software with many advanced features most desktop users never need. Rights assignments in Sudo can be regulated by role-based access controls [1] and by mandatory access controls [2] or configured via LDAP and the Network Information Service (NIS) directory service.

A very complex configuration file can result from all these options. All this complexity can quickly overtake newcomers, provoking errors which can compromise security.

Too Powerful for Home

The special powers of Sudo might make sense for a large and busy enterprise server, but many users believe Sudo is too big (with more than 412,000 lines of code) and too complicated for a single desktop user at home.

Because of its powerful and arcane feature set, Sudo is also a magnet for hackers. In the past, Sudo has been the subject of several security-critical bugs, most recently in January 2021 [3]. These bugs remained undiscovered for up to 10 years because of the complexity of the Sudo code.

Because the vast majority of users only need a minimal fraction of Sudo's powers, for many, it makes sense to use an alternative. Doas has emerged recently as a compact counterpoint to Sudo. At 4,000 lines, Doas contains only one percent of the code in the bloated Sudo and thus represents a far smaller attack vector. The reduced functionality means Doas might not be appropriate for complex enterprise environments, but it is all you need for many desktop systems.

Even on a system with several users, the Doas configuration file typically consists of a single line for each user, written in plain language. This simplicity reduces the likelihood of configuration errors, but Doas also lets you create more complex authorization systems if necessary.

Doas and OpenDoas

Doas development started about six years ago at OpenBSD, when Ted Unangst set out to implement 95 percent of Sudo's functionality with a far smaller codebase. Doas is now the standard in some BSD distributions, and you can install it via the repositories of many Linux distributions using the opendoas package [4]. On Linux, Doas almost always takes the form of the OpenDoas fork. Versions of OpenDoas also run on macOS [5].

Version 6.8.1 of the actively developed OpenDoas is currently available. If your distribution offers an older version of OpenDoas or doesn't have it at all, as is the case in Debian 10, you can get the source code from Github [6] and build it yourself using the three familiar Linux commands (Listing 1). If the last command fails, check if the path and filename match. You'll also have to take care of the PAM configuration to secure Doas [7]. A suitable template for PAM is /etc/pam.d/sudo.

# Preparation:
sudo apt install build-essential checkinstall git byacc
# Deploy
git clone git://github.com/Duncaen/OpenDoas --depth 1
cd OpenDoas
# build
./configure --with-timestamp --mandir=/usr/share/man
make
checkinstall  -D --install=no --maintainer=user --pkgname=opendoas
# Install
sudo apt install /home/$USER/OpenDoas/opendoas_*.deb

Once you have OpenDoas installed on your system, the best way to test it is to simply prepend doas instead of sudo to a command. If you see an error message, the problem is probably due to your distribution – some maintainers ship OpenDoas without a configuration file.

The config file is quickly created, along with the entry required for the current user, with a single command (Listing 2, Line 2) (Figure 1). On multi-user systems, you would authorize all members of the admin group with the command from Listing 2, Line 4.

01 # Enter your own user account
02 echo "permit :$USER" | sudo tee /etc/doas.conf
03 # Define admin group as allowed group
04 echo "permit :admin" | sudo tee /etc/doas.conf
05 # Deny command for current user
06 echo "deny :$USER apt update && apt dist-upgrade" | sudo tee /etc/doas.conf
07 # Use without password for current user
08 echo "permit nopass :$USER" | sudo tee /etc/doas.conf
09 # Preserve environment variables
10 echo "permit keepenv :$USER" | sudo tee /etc/doas.conf

Figure 1: Usually a single line in the configuration is enough if there is only one user on the system.

If you want to configure deployment for another user, either add the user to a group or replace $USER with the appropriate account name in the commands in Listing 2.

The deny keyword in /etc/doas.conf denies users certain privileges (Listing 2, Line 6). On single-user systems, it might be a good idea to use the software entirely without a password (Listing 2, Line 8).

Most of the time it is not advisable to start GUI applications as root, but apps such as Gparted or Krusader-Root need these permissions already at startup. To allow these graphical applications with Doas, the keepenv parameter comes into play (Listing 2, Line 10).

Persistence and Autocompletion

OpenDoas, unlike Sudo, does not remember the password. Sudo stores the password for 15 minutes, but Doas theoretically requires you to enter it again with every command.

If you want to emulate the persistence of Sudo (15 minutes) with OpenDoas on Debian and derivatives, you need to compile the application yourself with the --with-timestamp option (Figure 2).

Figure 2: The persist option is only available if you build Doas yourself from source code. To do this, add the --with-timestamp parameter to the ./configure command.

Another difference between Doas and Sudo is that Doas does not enable autocompletion in most distributions. The lack of an autocompletion feature means that, if you prefix the command with doas, the shell does not complete commands when you press the tab key. This is annoying if you are used to autocompletion. A bug report from the author has not yet been processed, but you will find a workaround in the box entitled "Bash completion."

PATH=$PATH:/sbin:/usr/sbin:/usr/local/sbin

sudo touch /usr/share/bash-completion/completions/doas

Figure 3: Add the path variable as the second line of the completion file created previously as a workaround. If you then replace the occurrences of sudo with doas, Bash completion will also work after a restart.