Open JWMKit opened 2 months ago
What exactly gave you that impression?
OK I have egg on my face. Sorry about that. I'll edit my original post so not to spread miss-information. I don't know why I had the problem when I tested it.
So yes the nopass part was wrong
On the other had it still will runs the fake command as root with the password
So it's not as serious, but but it does seem you could trick a user with a fake executable.
They would happily give their password if they thought they were running a known command like man
or apt
or maybe I'm a little paranoid.
If someone can write into $HOME/bin
they can just as well write into your shell config and change all kinds of behavior. doas
could be a function which does $whatever
with your password. Do you run type doas
every time before you call doas
to see if it's been overridden? What if they fully replace your shell and now not even /usr/bin/doas
is safe?
I think you're being paranoid (or not enough :p)
But if that's important to you, change the config to set a known PATH for that rule!
I think it's a reasonable concern, so I'll be changing it in my own config. But I'm not gonna fall for some random guy on the internet telling me to save a file in my exec path, so It's not me that need the config, but better safe than sorry.
EDIT : Thanks for your time. I'll leave the issue open in case you have unfinished business.
I can't close it, that'd be up to Duncaen
doas should prefer executables in system PATH over local (in $HOME)
or maybe it should ignore the local paths?
worse case example
assume this line is in the doas.confpermit nopass user as root cmd poweroff
and
~/.local/bin
is in the user's exec PATHIf you create a "Fake" poweroff executable in ~/.local/bin
then run the command
doas poweroff
it will run the fake poweroff as root instead of the real one
Things to consider: ~/.local/bin does not require root access to write
no password is requested thanks to the nopass configuration.*Edited due to inaccuracy. See below
Addition : This does not apply to commands specifically specified with nopass