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

safe --target target sometimes makes sense #224

Open
dennisjbell opened this issue Nov 12, 2020 · 3 comments
Open

safe --target target sometimes makes sense #224

dennisjbell opened this issue Nov 12, 2020 · 3 comments

Comments

@dennisjbell
Copy link
Contributor

Obviously, safe --target <x> target doesn't make a lot of sense on its own, but there are conditions where it does make sense.

The most crucial is when the safe target is being specified by the SAFE_TARGET environment variable. In this case, safe outright lies to you when you run safe target because internally, there is no difference between overriding the target with --target or by use of the environment variable.

The scenario:

$ export SAFE_TARGET=prod
...some time later...
$ safe target sandbox
$ safe target

Specifying --target to the target command makes no sense; ignoring...
Currently targeting sandbox at https://10.10.0.4
Skipping TLS certificate validation
Uses Strongbox at http://10.10.0.4:8484/strongbox

$ safe rm -rf secret/*
# Oh-noes - prod secrets all gone!

In this case, safe target should return whatever target will be used when safe is called in that environment.

Similarly, when running safe target --json in order to get the current target information in a json format, safe currently gives the .saferc 'current' target details, not the target in that environment. It even makes more sense to support the explicit --target <x> option in this case for when you want to read details about a specific target without changing the actual target.

@jhunt
Copy link
Contributor

jhunt commented Nov 12, 2020

Bear in mind that fixing this doesn't magically make the implicit target TOCTOU race condition check go away, with respect to rm.

A scenario that is still dangerous:

me@term1 $ safe target sandbox
me@term1 $ safe target

Currently targeting sandbox at https://10.10.0.4
Skipping TLS certificate validation
Uses Strongbox at http://10.10.0.4:8484/strongbox

... switch to another terminal, same box ...
me@term2 $ safe target production

... switch back to where it says i'm targeting sandbox ...
me@term1 $ safe rm -rf secret/*
# oh noes!! where my prod secrets at?!

@tofds
Copy link

tofds commented Mar 10, 2021

We are facing the same impediment working with various vaults.
Especially switching between terminals pointing to different vaults may result in lost or misdirected secrets, as jhunt pointed out.

I can either use "safe target " in my shell, OR use "export SAFE_TARGET="" ", but mixing them appears to be a bad idea.
But unless we remove the ~/.saferc there is no way to UNSET the "safe target".

The goal would be to be able to work with various shells, each pointing to a separate vault without the shells affecting each other.

@umutkacar
Copy link

I share the concerns stated above. Please make safe, "safe" to operate against separate Vault instances on different terminal panes.

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

4 participants