The Problem with sudo
Over the years, sudo has become the de facto privilege escalation program in the UNIX world. However, this means that sudo has to cater to every use-case for every person that is using a UNIX-like machine. This approach in program development made sudo an unwieldy program that is hard to understand and hard to use. For example, to modify sudo’s behavior, you need to run a command called visudo. This is a special loader program that opens the “/etc/sudoers” file in a “safe mode.” Visudo does a couple of things: it routinely checks for syntax errors in the “/etc/sudoers” file and locks the “/etc/sudoers” file so that no one other than the current user can edit the file. These might seem to be useful on the surface, but visudo is a symptom of sudo’s increasing complexity. This means that the syntax of the sudoers file has become complicated enough that it became necessary to check for potential syntax errors. This also means that sudo has to cater to both single-user and multi-user environments, therefore necessitating the need to lock the sudoers file for the current user. Sudo is a wonderful program. Its complex configuration syntax can create elaborate permission systems which can be potentially useful for an experienced system administrator. To most users, however, we only use sudo to run a root shell to install programs and tinker with our systems. Sudo’s complexity, therefore, appears to be more of a hindrance rather than a feature in those cases.
Why Use doas?
The intention of Doas is to solve the complexity of sudo. It was developed for OpenBSD and was quickly ported to just about any Linux system. It aims to be quick and easy to use but also simple to maintain and secure. The syntax of doas is also different than sudo. Configuring it is similar to writing in plain English. In sudo, for example, the syntax to allow any user of the group wheel to execute as root without any password is: In doas, meanwhile, the syntax is far easier to understand: Furthermore, doas does not need any special loader program like visudo to modify its configuration. The user only needs to edit the configuration file with any text editor, and as long as the user has sufficient privileges, they would be able to make changes in the configuration. This makes doas easier to understand and make sense of. Its simplistic and plain approach to creating privileged users and groups makes the process transparent and error-free for the user.
How to set up doas with sudo
If you are using a Linux system, there is a good chance that you are already using sudo as your privilege escalation program, and that makes installing doas relatively straightforward. In Debian and Ubuntu, you can install doas using apt: In Arch Linux, you can use pacman: With Fedora, you can use dnf: For Void Linux, you can use xbps: In my case, I am installing doas on Void Linux, so I am using XBPS.
The doas Configuration File
With doas installed, you can now edit the “/etc/doas.conf” file by switching to the root user using su. Su will ask for your root password, and after that, it will either open or create the configuration file using nano. Once done, you may notice that “doas.conf” is empty. This is completely different compared to visudo. But as we discussed earlier, configuring doas is relatively trivial.
The Configuration Syntax
The syntax for doas.conf is as follows:
Permit and Deny will set whether doas will allow the rule.Options are additional configurations for doas. The most useful options for the regular user are persist and nopass.Identity is the user or group that is executing doas.as target is the user that the “Identity” can or cannot run as.cmd is the command that the “Identity” can or cannot run “as target.” The default is all programs, but you can specify a particular program in this field.args are the arguments that are specific for the command that you have indicated.
For example, writing the following will enable any user in the wheel group to execute commands as root. The root shell will also persist until the window is closed. You can also create a rule that only targets a specific user for a specific command. For example, you can use the following rule to allow the user “bob” to run the “apt” program as root without asking for any password. In my case, I want the group “wheel” to run as root without any password. I also do not want the user aga, who is part of the wheel group, to run any commands as root. So I will be writing the following in my “/etc/doas.conf”:
Post-Configuration
After that, you have to execute a few commands to make sure that doas is working as intended. First, you will need to properly set the owner of doas.conf to root: You will also need to set the file permissions of the configuration file to 0644 to make sure the file will only be accessible to the root user. Lastly, you will need to check doas itself for any syntax errors within the configuration. To do this, run the following command: Congratulations! You have successfully installed and configured doas for your system. You can now start using doas as a substitute for sudo or fine tune your doas.conf file to your liking. For more information about system administration in Linux, you can read this article.
1. My configuration does not seem to work. I have added a rule for a specific user and a general rule but the rule for the user does not seem to work.
The doas configuration file works from the most general rule down to the most specific one. For your configuration to work, you need to first specify the rule that applies to all users. You can then specify the rule targeting a single user underneath it.
2. Is it possible to retain sudo and doas in the same system?
Yes! Doas and sudo are two different programs. They do not conflict with each other, and it is fine to leave sudo on the system and use doas.
3. Is it possible to get a root shell using doas?
Yes, provided you have properly configured your configuration file. You can initiate a root shell by running doas -s.
