doas - sudo alternative

doas is a sudo alternative ported from openbsd

install doas

Bash:
# pkg install doas

create the doas config file

Bash:
# vi /usr/local/etc/doas.conf

add the following code to the doas.conf file

Bash:
permit nopass keepenv :wheel
permit nopass keepenv root as root

make sure your user is in the wheel group

The syntax is:

Bash:
pw group mod {GROUP-NAME-HERE} -m {USERNAME-HERE}
pw group mod wheel -m username

instead of allowing members of the wheel group to execute commands as root without a password which may be a security issue,you can just allow your user to execute commands as root without a password,
by replacing username with your username in the code below

Bash:
permit nopass keepenv :username
permit nopass keepenv root as root

to switch to root using doas

Bash:
doas su

read the man page for more details

enable auto completion for doas and bash

edit your ~/.bashrc

Bash:
vi ~/.bashrc

add the following code to your ~/.bashrc to enable doas bash auto completion

Bash:
complete -cf doas

source your ~/.bashrc

Bash:
. ~/.bashrc
 
Last edited:
I'd stick to the topic.
shells/bash is completely irrelevant here and it's not FreeBSD's default shell. Even worse, it's a port.

A good howto does not build upon personal preferences. Any personal preference should at least be clearly marked as none default.

I don't get the point of doas su. What's that supposed to do?
Sorry for the critics.

Besides that, good to let more people know about security/doas.
 
I am d'accord with k.jacker. In a How-To you should take distance from your personal preferences and configurations. There are many more configuration possibilities for security/doas and you should start with the default behaviour and then shortly present the other options and commands.


permit nopass keepenv :wheel
permit nopass keepenv root as root
Form a security perspective Im not sure if it is recommended to allow the wheel group running every command without a password. I know that some Linux distros disable the root account and give all admin rights to the first user by default. But such a configuration is at least doubtful. I use doas for some scripts but restrict the nopass option to the needed commands only (in conjunction with args). But thats just my preference :).

Anyway, thanks for shifting attention to security/doas.
 
Hi Mate

The reason i mentioned bash was because auto completion wasnt working with doas for me without that fix

So its not really off topic because its an issue that related to doas that may affect other people who use bash,
which isnt the default shell granted but it used by quite a lot of people and i thought it best to mention it in the how up front,
rather than letting people set up doas find the bug for themselves after the fact and get frustrated that auto completion wasnt working and that i didnt mention the issue and the fix for it

doas su is the same as sudo su it switches to the root prompt #
whereas running doas somecommand, runs that command as root

no problem with the critic, always good to have feedback

if you havent tried doas id give it a go, its really good
 
I am d'accord with k.jacker. In a How-To you should take distance from your personal preferences and configurations. There are many more configuration possibilities for security/doas and you should start with the default behaviour and then shortly present the other options and commands.



Form a security perspective Im not sure if it is recommended to allow the wheel group running every command without a password. I know that some Linux distros disable the root account and give all admin rights to the first user by default. But such a configuration is at least doubtful. I use doas for some scripts but restrict the nopass option to the needed commands only (in conjunction with args). But thats just my preference :).

Anyway, thanks for shifting attention to security/doas.
H Mate

I agree about the issue of letting the wheel group run commands without a password,
you can change the wheel group to your own user instead in the doas config,
i should have mentioned that good point

The example i used was taken from the doas man page

One issue with doas on freebsd is the persist option doesnt work, that only works on openbsd
So doas wont remember you password for 5 minutes like sudo, if you select persist you have to enter you password everytime

The reason i mentioned bash completion and doas was because it was an issue i came across that may affect other people,
so i thought it was a good idea to document the issue and the fix in one place
 
I am d'accord with k.jacker. In a How-To you should take distance from your personal preferences and configurations. There are many more configuration possibilities for security/doas and you should start with the default behaviour and then shortly present the other options and commands.



Form a security perspective Im not sure if it is recommended to allow the wheel group running every command without a password. I know that some Linux distros disable the root account and give all admin rights to the first user by default. But such a configuration is at least doubtful. I use doas for some scripts but restrict the nopass option to the needed commands only (in conjunction with args). But thats just my preference :).

Anyway, thanks for shifting attention to security/doas.
Hi Mate

I changed the how to guide and added a note that allowing the wheel group to execute commands as root may be a security issue, and it may be better to just allow your user to execute commands as root without a password

The wheel example is actually from the doas man page,
maybe the man page should default to showing a config to allow just your user and not the whole wheel group

thanks for the feedback
 
I changed the how to guide and added a note that allowing the wheel group to execute commands as root may be a security issue, and it may be better to just allow your user to execute commands as root without a password

Hi,

I'm not certain I know what you mean. My /root/.cshrc file has root as the owner and wheel as the group. Allowing the usr to execute commands as root is a problem for me, too.

Maybe it's just me as I've never used anything but su to issue commands as root.
 
Hi,

I'm not certain I know what you mean. My /root/.cshrc file has root as the owner and wheel as the group. Allowing the usr to execute commands as root is a problem for me, too.

Maybe it's just me as I've never used anything but su to issue commands as root.
Using doas you can allow a user or a group and all the members of that group to execute commands as root without using a password

But allowing the entire wheel group and all its members to execute commands as root without having to use a password would be a security issue

If would be like putting the wheel group in the sudoers file and not requiring a password for members of the wheel group to use sudo

You can also use doas to allow users to run only certain commands as root,
for example ifconfig to configure the network but not shutdown or reboot

there is a good article called doas mastery that is worth a read
 
I have security/doas installed but 99.99% I am using su:)

I used to have that habit too. How I got out of it was to remove my user account from the "wheel" group and make a specific sudo / doas entry for it.

Then for stuff I do regularly such as reboot, shutdown, mount, sleep, etc, I then set to be passwordless (nopass in doas and NOPASSWD in sudo).
 
Don't trust X myself. As I'm just running a single user desktop setup I never run su, doas, sudo within X, only from a console/tty. Under OpenBSD X runs as user, and I've set all setuid's off for 'others', and user isn't a member of any groups (not wheel etc.) so as good as contained. doas is only really useful in a real multi-user setup.

As a test, open a xterm window and su to root. Open another xterm window as user. If that user xterm can use something like xdotool to windowactivate the root xterm window then there's potential risk for it to also send command sequences to that window i.e. run root commands. If a single browser flaw opens up remote command execution then it could do similar even though the browser might be running under a restricted userid.

When running root on a tty I tend to use tmux and a tput menu that I created that contains regular commands/actions. So for instance reboot for me is ctrl-alt-F4 to access the root/tmux/tput menu, and 'r' to trigger a reboot action (p for powerdown, l to mount a linux/ext2 partition, a to mount my android phone ...etc.).
s.png
 
Back
Top