4 ms·

If you think that putting secrets in ENV is bad, you probably shouldn't take the advice of running 'docker service create --secret="secure-secret" redis:alpine

If you think that putting secrets in ENV is bad, you probably shouldn't take the advice of running 'docker service create --secret="secure-secret" redis:alpine' either! Putting secrets in a command line makes them just as visible, in fact more so, to other processes. It also makes the secrets available to anyone regardless of permissions, since everyone can monitor the currently running processes and their args (e.g. a 'ps waux' or 'cat /proc/12345/cmdline')

photon12 6y ago
Aren't these equivalent, given that the /proc/x/environ file exists?
- joosters 6y ago
  /proc/x/environ is similar, but has more restrictive permissions: user-readable only, whereas /proc/x/cmdline is world-readable.
  - photon12 6y ago
    Fair point. Though I feel like in any modern app deployment scenario that isn't going to be a meaningful defensible boundary. The answer is to use neither, especially given the number of times I've used a path traversal vulnerability to expose /proc/self/environ on a pentest, and the one time I was frustrated on a pentest when every app in the environment used a dedicated API for secret retrieval and the path traversal vulnerability I had access to was worthless.
    - imtringued 6y ago
      How do docker secrets solve the problem then? According to the article they store the secret in a file as well. You could access the docker secret just as easily as environment variables. The only meaningful difference is that /proc/self/environ will return all secrets at once meanwhile with docker secrets you have to know the file path.
      - photon12 6y ago
        They don't There's a lot of bad advice on secret storage that is Not Based On A Threat Model™
IshKebab 6y ago
`secure-secret` is not the secret itself. It is the name of the secret.
- joosters 6y ago
  Oops, my bad. I saw the '--secret="secure-secret"' part of the command and assumed that was the secret itself! Thanks for the correction.
jdxcode 6y ago
they wind up in your bash history this way too

photon12 6y ago

Aren't these equivalent, given that the /proc/x/environ file exists?

joosters 6y ago
/proc/x/environ is similar, but has more restrictive permissions: user-readable only, whereas /proc/x/cmdline is world-readable.
- photon12 6y ago
  Fair point. Though I feel like in any modern app deployment scenario that isn't going to be a meaningful defensible boundary. The answer is to use neither, especially given the number of times I've used a path traversal vulnerability to expose /proc/self/environ on a pentest, and the one time I was frustrated on a pentest when every app in the environment used a dedicated API for secret retrieval and the path traversal vulnerability I had access to was worthless.
  - imtringued 6y ago
    How do docker secrets solve the problem then? According to the article they store the secret in a file as well. You could access the docker secret just as easily as environment variables. The only meaningful difference is that /proc/self/environ will return all secrets at once meanwhile with docker secrets you have to know the file path.
    - photon12 6y ago
      They don't There's a lot of bad advice on secret storage that is Not Based On A Threat Model™

IshKebab 6y ago

`secure-secret` is not the secret itself. It is the name of the secret.

joosters 6y ago
Oops, my bad. I saw the '--secret="secure-secret"' part of the command and assumed that was the secret itself! Thanks for the correction.

jdxcode 6y ago

they wind up in your bash history this way too