I started working on doas quite some time ago after some personal issues with the default sudo config. The “safe environment” was under constant revision and I regularly found myself unable to run pkg_add or build a flavored port or whatever because the expected variables were being excised from the environment. If I had been paying attention, keeping sudoers up to date probably would not have been such an ordeal, but I don’t like change.

The core of the problem was really that some people like to use sudo to build elaborate sysadmin infrastructures with highly refined sets of permissions and checks and balances. Some people (me) like to use sudo to get a root shell without remembering two passwords. And so there was considerable tension trying to ship a default config that would mostly work with the second group, but not be too permissive for the first group.

Writing a small simple replacement meant that we could ship something in base which was totally unsuitable for the power sysadmin group. It could only work for me, and I would be happy. Meanwhile, those who truly needed all the flexibility of sudo would install it from ports, and they would be happy.

The code was just sitting around in a spare source tree for a while because any “like this, but different” software release immediately results in a flood of email. “It’s different!” And despite my reasoning above, I seemed to be the only person actually unhappy with the situation, so there was no motivation to add the necessary polish to reach minimal replacement level.

Talking with deraadt and millert, however, I wasn’t quite alone. There were some concerns that sudo was too big, running too much code in a privileged process. And there was also pressure to enable even more options, because the feature set shipped in base wasn’t big enough. (As shipped in OpenBSD, the compiled sudo was already five times larger than just about any other setuid program.) Hurray, tension. It wasn’t the problem I was trying to solve, but it was an opening from which to launch my diabolical plan.

First, doas needed a new name because nobody ever likes the first name. A few suggestions were made. sux (already taken by su, now with more X. machtfrei (too many letters). powershell (if only). datass (submitted after contest end).

In to cvs it went as doas. Incidentally, doas appears to be an alternative (mis)spelling for duas, but the initial commit was a few days late for Laylat al-Qadr.

And then the real hacking and chopping could begin. I always thought the most important feature of sudo was that it insulted the user after entering a bad password. Apparently the world is filled with poor typists; the first diff to doas was to add a config option noinsults. Unfortunately, this was a poor compromise that complicated the grammar and required further documentation, so the feature was dropped entirely. There was also another proposal to change the error message from “Permission denied” to “Sorry” to match su, but not implemented. doas will not apologize for your failures.

Deleting a dozen lines of insults made space for one new feature. A simple -s option is almost compatible with sudo if muscle memory proves too difficult to overcome.

The config file syntax is crudely inspired by pf.conf. Instead of pass and block keywords, there are permit and deny keywords. There are some limitations. Trying to deny a single command can be tricky because “ksh” and “/bin/ksh” and “/bin/ksh” are all interpreted differently. Don’t do that. My instinct was that adding deny as a means to counteract permit was a natural idiom; certainly that’s how pf works. In retrospect though, a default pass ruleset already is the default, while permit default is certainly not. The keyword should perhaps be escalate. Phrasing it as trying to remove escalation after granting it makes the potential danger more clear. We’ve been contemplating a different config syntax which reverses the ordering of user and command. Instead of a user focused approach, specify the command first, then the set of permitted users. It should be equivalent in expression, but perhaps the reversed order would encourage users to think about minimal permission grants. I’m not entirely convinced, but I would like it to be at least as natural to express a secure, limited config as a convenient, permissive config. Coming full circle, the majority of tweaking and polishing of doas now appears to have returned to refinement of the good environment list and the bad environment list. I have built the thing I hate. At least it’s small. The doas code lives in cvs. doas was created to run on OpenBSD. I suppose you could port it, but I don’t plan to. Figuring out a replacement for auth_userokay is probably the hard part. The 'doas' command provides a way to perform commands as another user. It aims to be a a simplified and lightweight replacement for [[Sudo|sudo]]. The doas tool was originally written for [https://www.openbsd.org/ OpenBSD] by Ted Unangst. OpenDoas is a port of doas for Linux, which is available as the app-admin/doas package. == Installation == === USE flags === package=app-admin/doas === Emerge === app-admin/doas == Configuration == The doas tool is configured by the ruleset specified in /etc/doas.conf. By using an empty configuration file the default ruleset will be applied which denies all actions. === Basic configuration === A simple skeleton configuration could be to specify a rule which allows all users in the wheel group to perform any action as root. filename=/etc/doas.conf|title=Allow all users in the {{c|wheel group to execute any command as root|1= permit :wheel }} It's also possible to deny certain actions to specified users. The ruleset is evaluated in a hierarchical manner, thus adding a new rule can override the previous one: filename=/etc/doas.conf|title=Deny a user to execute a command|1= permit :wheel deny larry cmd fdisk The user larry is part of the wheel group and therefore may perform actions available to root, but the second rule denies this user access to the fdisk command. === Authentication === The nopass keyword provides the ability to perform actions without having to enter a password: filename=/etc/doas.conf|title=Allow all users in the {{c|wheel group to perform actions as root without authentication|1= permit nopass :wheel }} Due to OpenBSD-specific kernel API required by {{c|doas to set and clear timeouts, the persist feature is disabled by default in the OpenDoas port.}} With the persist keyword doas can remember an authenticated user and will not require confirmation by password for five minutes: filename=/etc/doas.conf|title=Do not require passwords for five minutes for all users in the {{c|wheel group|1= permit persist :wheel }} === Commands === The doas tool allows the creation of rules which only apply to certain commands. A rule can be specified to allow a certain user to use a command only available to root: filename=/etc/doas.conf|title=Allow a user to use the {{c|reboot command without a password|1= permit nopass larry cmd reboot }} This allows the user larry to execute the reboot command without having to enter a password. This may allow users to use restricted commands without providing complete root access. === Testing === A configuration file can be tested as follows: doas -C /etc/doas.conf Specifying a command will show you whether you have permissions to perform this command: doas -C /etc/doas.conf cat This test will output deny if you do not have the permissions to execute cat. You can also check permissions for a specified user: doas -C /etc/doas.conf cat -u larry If the user larry has permissions to access cat it may output permit. === Targets === The doas can not only be used to perform actions with root privileges, it also allows to target certain users and groups. The syntax to distinguish between groups (like :wheel) and users (like larry) is a leading colon. filename=/etc/doas.conf|title=Allow a user to perform actions as another user|1= permit nopass larry as postgres By adding this rule, the user larry is allowed to perform actions as the postgres user without having to enter a password. === Bash tab completion === By default bash will only tab complete files and directories within the current or referenced directory. To tell bash to complete arguments as if they were separate commands (also leveraging the tab completion settings of other commands) the following can be added to either the users .bashrc, or the global /etc/bashrc. filename=~/.bashrc|title=Configure tab completion|lang=bash|1= # Configure completion for doas # -c : Complete arguments as if they were commands # (eg: `doas emer<tab>` -> `doas emerge`) # (eg: `doas dd status=p<tab>` -> `doas dd status=progress`) # -f : Complete arguments as if they were directory names (default behaviour) # (eg: `doas /bi<tab>` -> `doas /bin/`) complete -cf doas == Usage == The doas command can be used like sudo: doas emerge -uDN world See [https://man.openbsd.org/doas doas(1)] for more information. == See also == * sudo == External resources == * [https://man.openbsd.org/doas.conf.5 doas configuration file man page] Software