# doas - sudo alternative



## NapoleonWils0n (Jan 18, 2019)

doas is a sudo alternative ported from openbsd

install doas


```
# pkg install doas
```

create the doas config file


```
# vi /usr/local/etc/doas.conf
```

add the following code to the doas.conf file


```
permit nopass keepenv :wheel
permit nopass keepenv root as root
```

make sure your user is in the wheel group

The syntax is:


```
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


```
permit nopass keepenv :username
permit nopass keepenv root as root
```

to switch to root using doas


```
doas su
```

read the man page for more details

enable auto completion for doas and bash

edit your ~/.bashrc


```
vi ~/.bashrc
```

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


```
complete -cf doas
```

source your ~/.bashrc


```
. ~/.bashrc
```


----------



## k.jacker (Jan 19, 2019)

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.


----------



## twllnbrck (Jan 19, 2019)

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.




NapoleonWils0n said:


> 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.


----------



## NapoleonWils0n (Jan 19, 2019)

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


----------



## NapoleonWils0n (Jan 19, 2019)

Lanakus said:


> 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.
> 
> 
> 
> ...


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


----------



## NapoleonWils0n (Jan 19, 2019)

Lanakus said:


> 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.
> 
> 
> 
> ...


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


----------



## Deleted member 30996 (Jan 19, 2019)

NapoleonWils0n said:


> 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.


----------



## fernandel (Jan 19, 2019)

Trihexagonal said:


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


I have security/doas installed but 99.99% I am using `su`


----------



## NapoleonWils0n (Jan 19, 2019)

Trihexagonal said:


> 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


----------



## NapoleonWils0n (Jan 19, 2019)

fernandel said:


> I have security/doas installed but 99.99% I am using `su`


I use doas somecommand for a single command and doas su to switch to root


----------



## kpedersen (Jan 20, 2019)

fernandel said:


> 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).


----------



## rufwoof (Jan 20, 2019)

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.).


----------

