5 ms·

No mention of `pass`? Certainly solves all my needs, and works well for version controlling secrets across a team. The only annoying thing about `pass` is the

No mention of `pass`? Certainly solves all my needs, and works well for version controlling secrets across a team. The only annoying thing about `pass` is the generic name, so searching for information on it, or dealing with issues is a pita. Luckily, there are few. Edit: I was wrong about what this article covers. Which is how to pass secrets to processes without leaking to `ps` or audit log. ---- Pass is still worth a look, https://www.passwordstore.org/ https://www.passwordstore.org/ Keeping the password storage in a gitlab repo makes it very useful for managing those secrets internally. Keep the list of public gpg keys for each team member, and a README, some helping initialization script for setting it up, and that's pretty much it. Then, all cases presented where the command would either be used directly in the command line, or within another script, is just replaced with a call to $(pass the/secret/we/need)

maweki 5y ago
How does pass solve this problem? Surely entering "command `pass accountdata`" has the same problem that the secret shows up in ps as command's argument.
- okamiueru 5y ago
  I see. I should have read the article more closely before commenting. I made a bad assumption based on the comments I saw here. The article is more about avoiding leaking the password than actually dealing with managing passwords in command lines. A few comments on the actual article, which was a lot more insightful than I had thought: - Protecting yourself from an audit logs is not really worth the effort, as the audit log should be treated as confidential as the secrets themselves. - Utilities can themselves hide arguments, and will not show on the ps output. For example, `mysqlsh` shows as `--password=********`, as does `mysql`. I'm not 100% if modifying argv data has any effect on /proc, but then again, if you are protecting yourself from something that can access /proc (i.e. root), then nothing will work in the end. Protecting yourself from a rogue process that can monitor `ps` is also already a lost battle.
  - Hello71 5y ago
    > if you are protecting yourself from something that can access /proc (i.e. root) on Linux and all other Unix-like systems I know of, all users are allowed to list running processes and their command lines. > Protecting yourself from a rogue process that can monitor `ps` is also already a lost battle. ps is not a privileged command on most systems. POSIX says "On some implementations, especially multi-level secure systems, ps may be severely restricted and produce information only about child processes owned by the user."; "severely restricted" implies that this is not a common behavior. furthermore, the article explains clearly how to hide secret arguments from ps. that's the main point of the article.

maweki 5y ago

How does pass solve this problem? Surely entering "command `pass accountdata`" has the same problem that the secret shows up in ps as command's argument.

okamiueru 5y ago
I see. I should have read the article more closely before commenting. I made a bad assumption based on the comments I saw here. The article is more about avoiding leaking the password than actually dealing with managing passwords in command lines. A few comments on the actual article, which was a lot more insightful than I had thought: - Protecting yourself from an audit logs is not really worth the effort, as the audit log should be treated as confidential as the secrets themselves. - Utilities can themselves hide arguments, and will not show on the ps output. For example, `mysqlsh` shows as `--password=********`, as does `mysql`. I'm not 100% if modifying argv data has any effect on /proc, but then again, if you are protecting yourself from something that can access /proc (i.e. root), then nothing will work in the end. Protecting yourself from a rogue process that can monitor `ps` is also already a lost battle.
- Hello71 5y ago
  > if you are protecting yourself from something that can access /proc (i.e. root) on Linux and all other Unix-like systems I know of, all users are allowed to list running processes and their command lines. > Protecting yourself from a rogue process that can monitor `ps` is also already a lost battle. ps is not a privileged command on most systems. POSIX says "On some implementations, especially multi-level secure systems, ps may be severely restricted and produce information only about child processes owned by the user."; "severely restricted" implies that this is not a common behavior. furthermore, the article explains clearly how to hide secret arguments from ps. that's the main point of the article.