Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doas should prefer executables in system PATH over local #128

Open
JWMKit opened this issue Sep 18, 2024 · 5 comments
Open

doas should prefer executables in system PATH over local #128

JWMKit opened this issue Sep 18, 2024 · 5 comments

Comments

@JWMKit
Copy link

JWMKit commented Sep 18, 2024

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.conf
permit nopass user as root cmd poweroff

and ~/.local/bin is in the user's exec PATH

If 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

@ericonr
Copy link

ericonr commented Sep 18, 2024

OpenDoas/doas.conf.5

Lines 79 to 95 in b96106b

.It Ic cmd Ar command
The command the user is allowed or denied to run.
The default is all commands.
Be advised that it is best to specify absolute paths.
If a relative path is specified, only a restricted
.Ev PATH
will be searched.
.It Ic args Op Ar argument ...
Arguments to command.
The command arguments provided by the user need to match those specified.
The keyword
.Ic args
alone means that command must be run without any arguments.
.El
.Pp
The last matching rule determines the action taken.
If no rule matches, the action is denied.

What exactly gave you that impression?

@JWMKit
Copy link
Author

JWMKit commented Sep 18, 2024

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.

@ericonr
Copy link

ericonr commented Sep 19, 2024

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!

@JWMKit
Copy link
Author

JWMKit commented Sep 19, 2024

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.

@ericonr
Copy link

ericonr commented Sep 19, 2024

I can't close it, that'd be up to Duncaen

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants