Hacker News Reader

Comment by perlgeek | Hacker News Reader

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.

View on HN

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

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.

true most ppl will do it command line..

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?

I think what you mean by "interactive CLI" is reading from stdin, which seams to be supported.

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.

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.

> 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.

Yes FreeBSD got this one right.

on linux you can mount procfs with the option 'hidepid' to similar effect.

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

Yes but very easy to forget to do. BTDT.

Could you alias "vault" to " vault"?

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).

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.

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.

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.

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.

> 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.

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

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.

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.

All it takes is a WordPress vulnerability that lets someone run `exec` on your server.

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.

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.

Reply on news.ycombinator.com