5 ms·

It sounds very exciting. But, the first example made me flinch: $ vault write secret/foo value=bar Don't ever pass passwords on the command line. On linu

It sounds very exciting. But, the first example made me flinch: $ vault write secret/foo value=bar Don't ever pass passwords on the command line. On linux, other users can see your command line (ps aux), and it usually ends up in a shell's history file.

odiroot 12y ago
Put a space before the command and it's gone from the history, AFAIR.
- ams6110 12y ago
  Yes but very easy to forget to do. BTDT.
  - msutherl 12y ago
    Could you alias "vault" to " vault"?
    - gknoy 12y ago
      I doubt it. My history file shows all the git-related aliases I use (st, gd, gd-) rather than the expansions (git status, git diff, git diff --cached).
- lenish 12y ago
  This is only true in bash if HISTCONTROL contains ignorespace or ignoreboth (ignoreboth implies ignorespace and ignoredups), so you should check that before relying on this functionality.
mitchellh 12y ago
Absolutely true! We support values coming from the command-line, stdin, and files: https://vaultproject.io/docs/commands/read-write.html https://vaultproject.io/docs/commands/read-write.html So you should use what you feel is most secure given the data you're entering.
- sliverstorm 12y ago
  I think the argument is something like, why support a method that is insecure nearly all the time and leads less-experienced users to make the wrong choices. Good security software gently herds the non-expert to make good choices. Too many options, especially specialty risky options, don't help that goal.
  - zobzu 12y ago
    true most ppl will do it command line..
- kylequest 12y ago
  Why not use interactive CLI instead of command line CLI (like routers have) to avoid leaks through the shell command history and other related channels?
  - nunull 12y ago
    I think what you mean by "interactive CLI" is reading from stdin, which seams to be supported.
- mpdehaan2 12y ago
  This is why ansible-vault (which is not trying to do the same thing) spawned a temporary editor, and immediately upon save encrypted the file - it doesn't exist in history, nor is there a chance of leaving it behind on disk. There's probably a way to do what you have launching an editor with stdin, but I'd probably suggest documenting an example, to avoid the risk of leaving the secret around. Also +1 to removing the insecure history option. Documenting the stdin to use 'cat' or something that's not in the history would probably take care of that one.
ams6110 12y ago
How many people these days share their linux machine with anyone else? If you're the only user, first point doesn't matter. History file is a concern, but can be mitigated e.g. setting HISTIGNORE
- metric10 12y ago
  Depends on the situation. A Linux machine running as a server can still be accessed by multiple people. Also, a "user" could be a compromised process that can execute commands. Using stdin or a properly created file means one less possible attack vector.
  - skywhopper 12y ago
    Doesn't storing the secret in a file first violate half the point of this service? Once it's written to disk in plaintext it's just as recoverable as your shell history.
- ceejayoz 12y ago
  All it takes is a WordPress vulnerability that lets someone run `exec` on your server.
  - skywhopper 12y ago
    if you the sort to worry about vault's command line being a security risk, you shouldn't be managing your secrets from your wordpress host in the first place.
IgorPartola 12y ago
This is true on shared systems. But for example as I am setting up a brand new server, I might do this from there since I know I'm the only user. The second half of your complaint is solved (at least in bash) by adding a space character before the beginning of the command. Edit: am I wrong? If so, please explain, I really am curious.
Freaky 12y ago
> On linux, other users can see your command line (ps aux) On FreeBSD I like doing: /boot/loader.conf: mac_seeotheruids_load="YES" /etc/sysctl.conf: security.mac.seeotheruids.enabled="1" Which restricts users to seeing only their own processes. You can make exceptions for a specific group or users with the same primary group. I still don't put anything sensitive in a command line, of course.
- istvan__ 12y ago
  Yes FreeBSD got this one right.
- daurnimator 12y ago
  on linux you can mount procfs with the option 'hidepid' to similar effect.
- deleted 12y ago
  [deleted]
jolan 12y ago
Hopefully they use setproctitle() to erase it. Pretty sure this is what mysql does: jolan 4950 0.0 0.0 46164 8820 pts/12 S+ 16:06 0:00 mysql -uroot -px xxxxxxxx Probably still a race condition and can be viewed before it is erased but at least it would be something.
dmgbrn 12y ago
Unless you're on your personal laptop. It's a tricky question, one that we've spent a lot of time thinking about at my company (Conjur -- shameless plug, one of our use cases is secrets management). Obviously doing this on a server that others can access/pwn is a bad idea, but that's a very rare use case. Most secrets are being added via the command line from an admin's single user laptop. In the end, we've settled on what seems to be the same solution as Vault: support other sources (stdin, files, etc.), but allow the command line. That said, I think you're right that we should look into adding a warning for the CLI tools and placing more emphasis on this fact in our documentation.
- wslh 12y ago
  > Unless you're on your personal laptop. It persists in your shell history... your notebook is stolen, then... You can encrypt the filesystem but it is better to not have your secret information disseminated in your filesystem and computer memory.
eb0la 12y ago
Good point! When I want to run something on a server and I don't want it to end in the .history file, I always run vi and execute the commands inside it ( <esc>:!command ). It always shows in the process list; but for short-lived commands the opportunity window is small for an attacker.
tetha 12y ago
Honestly, I dislike the approach. I don't want to tell my mysql <hello, please allow the user foo to authenticate itself with the password bar> and my webapp <hello webapp, please use the user foo and the password bar for the mysql over there>. I want to tell the system <look, I have a user foo, and the webapp over there needs access to the mysql over here with that user. Make it so.> I don't need to know the password my application uses to access the database. I don't WANT that password. No human should ever see this password. And heck, if the system wants to, just swithc passwords every 60 minutes. I don't want to care.

odiroot 12y ago

Put a space before the command and it's gone from the history, AFAIR.

ams6110 12y ago
Yes but very easy to forget to do. BTDT.
- msutherl 12y ago
  Could you alias "vault" to " vault"?
  - gknoy 12y ago
    I doubt it. My history file shows all the git-related aliases I use (st, gd, gd-) rather than the expansions (git status, git diff, git diff --cached).
lenish 12y ago
This is only true in bash if HISTCONTROL contains ignorespace or ignoreboth (ignoreboth implies ignorespace and ignoredups), so you should check that before relying on this functionality.

mitchellh 12y ago

Absolutely true! We support values coming from the command-line, stdin, and files: https://vaultproject.io/docs/commands/read-write.html https://vaultproject.io/docs/commands/read-write.html So you should use what you feel is most secure given the data you're entering.

sliverstorm 12y ago
I think the argument is something like, why support a method that is insecure nearly all the time and leads less-experienced users to make the wrong choices. Good security software gently herds the non-expert to make good choices. Too many options, especially specialty risky options, don't help that goal.
- zobzu 12y ago
  true most ppl will do it command line..
kylequest 12y ago
Why not use interactive CLI instead of command line CLI (like routers have) to avoid leaks through the shell command history and other related channels?
- nunull 12y ago
  I think what you mean by "interactive CLI" is reading from stdin, which seams to be supported.
mpdehaan2 12y ago
This is why ansible-vault (which is not trying to do the same thing) spawned a temporary editor, and immediately upon save encrypted the file - it doesn't exist in history, nor is there a chance of leaving it behind on disk. There's probably a way to do what you have launching an editor with stdin, but I'd probably suggest documenting an example, to avoid the risk of leaving the secret around. Also +1 to removing the insecure history option. Documenting the stdin to use 'cat' or something that's not in the history would probably take care of that one.

ams6110 12y ago

How many people these days share their linux machine with anyone else? If you're the only user, first point doesn't matter. History file is a concern, but can be mitigated e.g. setting HISTIGNORE

metric10 12y ago
Depends on the situation. A Linux machine running as a server can still be accessed by multiple people. Also, a "user" could be a compromised process that can execute commands. Using stdin or a properly created file means one less possible attack vector.
- skywhopper 12y ago
  Doesn't storing the secret in a file first violate half the point of this service? Once it's written to disk in plaintext it's just as recoverable as your shell history.
ceejayoz 12y ago
All it takes is a WordPress vulnerability that lets someone run `exec` on your server.
- skywhopper 12y ago
  if you the sort to worry about vault's command line being a security risk, you shouldn't be managing your secrets from your wordpress host in the first place.

IgorPartola 12y ago

This is true on shared systems. But for example as I am setting up a brand new server, I might do this from there since I know I'm the only user. The second half of your complaint is solved (at least in bash) by adding a space character before the beginning of the command. Edit: am I wrong? If so, please explain, I really am curious.

Freaky 12y ago

> On linux, other users can see your command line (ps aux) On FreeBSD I like doing: /boot/loader.conf: mac_seeotheruids_load="YES" /etc/sysctl.conf: security.mac.seeotheruids.enabled="1" Which restricts users to seeing only their own processes. You can make exceptions for a specific group or users with the same primary group. I still don't put anything sensitive in a command line, of course.

istvan__ 12y ago
Yes FreeBSD got this one right.
daurnimator 12y ago
on linux you can mount procfs with the option 'hidepid' to similar effect.
deleted 12y ago
[deleted]

jolan 12y ago

Hopefully they use setproctitle() to erase it. Pretty sure this is what mysql does: jolan 4950 0.0 0.0 46164 8820 pts/12 S+ 16:06 0:00 mysql -uroot -px xxxxxxxx Probably still a race condition and can be viewed before it is erased but at least it would be something.

dmgbrn 12y ago

Unless you're on your personal laptop. It's a tricky question, one that we've spent a lot of time thinking about at my company (Conjur -- shameless plug, one of our use cases is secrets management). Obviously doing this on a server that others can access/pwn is a bad idea, but that's a very rare use case. Most secrets are being added via the command line from an admin's single user laptop. In the end, we've settled on what seems to be the same solution as Vault: support other sources (stdin, files, etc.), but allow the command line. That said, I think you're right that we should look into adding a warning for the CLI tools and placing more emphasis on this fact in our documentation.

wslh 12y ago
> Unless you're on your personal laptop. It persists in your shell history... your notebook is stolen, then... You can encrypt the filesystem but it is better to not have your secret information disseminated in your filesystem and computer memory.

eb0la 12y ago

Good point! When I want to run something on a server and I don't want it to end in the .history file, I always run vi and execute the commands inside it ( <esc>:!command ). It always shows in the process list; but for short-lived commands the opportunity window is small for an attacker.

tetha 12y ago

Honestly, I dislike the approach. I don't want to tell my mysql <hello, please allow the user foo to authenticate itself with the password bar> and my webapp <hello webapp, please use the user foo and the password bar for the mysql over there>. I want to tell the system <look, I have a user foo, and the webapp over there needs access to the mysql over here with that user. Make it so.> I don't need to know the password my application uses to access the database. I don't WANT that password. No human should ever see this password. And heck, if the system wants to, just swithc passwords every 60 minutes. I don't want to care.