Duncaen / OpenDoas

A portable fork of the OpenBSD `doas` command
Other
610 stars 35 forks source link

OpenDoas keeps current PATH variable #45

Closed ivan3182 closed 3 years ago

ivan3182 commented 3 years ago

OpenDoas version: 6.8 System: Gentoo, Debian 10 /etc/doas.conf content: permit :wheel

man doas says that variable PATH is set to value appropriate for the target user, but current value preserves:

user@gentoo /etc
> $ env | grep ^PATH
PATH=/home/user/.local/bin:/home/user/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/lib/llvm/10/bin

user@gentoo /etc
> $ doas env | grep ^PATH
doas (user@gentoo) password:
PATH=/home/user/.local/bin:/home/user/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/lib/llvm/10/bin

expected value:

user@gentoo /etc
> $ su -l
Password:
gentoo ~ # env | grep ^PATH
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/lib/llvm/10/bin
Duncaen commented 3 years ago

Thanks for the report, this is indeed a bug and this not matching the documentation I consider it a security issue and have requested a CVE for it (CVE-2019-25016), this used to be the default behavior but should have been correctly changed in 2019.

One nuance about this is that the users PATH will be used when executing the first command if the rule allows any command, so with the rule permit :wheel, PATH=~/bin doas foo will execute foo from ~/bin. If the rule limits the execution to a specific command then the "safe" PATH is used, permit :wheel cmd foo would not execute ~/bin/foo (in this case the reset the PATH variable was already correct before this fix).

This means before the fix, users who only had access to execute a specific command were not able to execute other command through a "unsafe" PATH.

Users who were allowed to execute anything could change PATH to execute more things from PATH.

This has been fixed in https://github.com/Duncaen/OpenDoas/commit/d5acd52e2a15c36a8e06f9103d35622933aa422d.

Duncaen commented 3 years ago

If you want to be credited in the CVE as Discoverer, please tell me a name and I will request an update for the CVE.

ivan3182 commented 3 years ago

After the fix (OpenDoas 6.8.1) it is possible to execute script from ~/.local/bin even though it is not in path Is this intentional?

user@gentoo ~
> $ cat /etc/doas.conf
permit :wheel

user@gentoo ~
> $ cat /home/user/.local/bin/check-doas.sh
#!/bin/bash

whoami
echo "${PATH}"

user@gentoo ~
> $ check-doas.sh
user
/home/user/.local/bin:/home/user/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/lib/llvm/10/bin

user@gentoo ~
> $ doas env | grep ^PATH
doas (user@gentoo) password: 
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin

user@gentoo ~
> $ doas check-doas.sh
doas (user@gentoo) password: 
root
/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin

on OpenBSD it says doas: check-doas.sh: command not found

Duncaen commented 3 years ago

Yes that is how it works for rules that allow a user to execute any command (permit :wheel), in this case the executing users PATH is used. For rules that allow to execute only specific commands (permit :wheel cmd check-doas.sh), the default path is used.

This is exactly how it works in the original doas and also in sudo.

on OpenBSD it says doas: check-doas.sh: command not found

Then you did not add ~/.local/bin to your PATH.