Support passing sensitive values on the command line via stdin

[KimBrodowski]

My employer configures servers automatically using custom configuration management solutions. We're currently in the process of integrating RabbitMQ.

While writing the configuration scripts I've noticed that rabbitmqctl doesn't appear to provide any means to securely pass the user's password using STDIN or the environment. Arguments are leaked through the process list and therefore unsuitable as a transport for secret tokens of any kind. This is particularly relevant on shared setups like hosting environments.

As a more complex alternative RabbitMQ offers to setup user credentials through the config, however secure configuration of users at runtime would be nice to have too.

Clarification from the discussion below.

Making passwords optional for the few commands that accept them and reading values from standard input is one option. It can be supplemented by a global --non-interactive switch that would fail argument validation instead of falling back to stdin.

[michaelklishin]

Passing sensitive arguments in the command line is not considered to be a very secure practice.

Definition import is an alternative available today which does not involve passing any values on the command line. Config value encryption is another but not very useful as only the seed user can be configured that way.

We can do something similar to how encrypted values are supported in the config file (e.g. CLI tools have a private key configured, encrypted values are prefixed with encrypted:… or similar) but I don't know how useful this would be. It would sure be a fairly complex feature we'd have to maintain forever.

[michaelklishin]

Another option is using HTTP API to create users. It supports precomputed password hashes instead of plain text passwords and, of course, HTTPS.

[KimBrodowski]

I don't know why passing passwords via STDIN isn't an option for you. It's the de facto standard in the UNIX world. The issue isn't that I need to pass the plaintext password - I'm fine with that. The issue is that every user on the system can see it in the process list when I do.

This can be done with very little effort. Make the password parameter optional, die if the program is running non-interactively and otherwise prompt for the password.

[michaelklishin]

@KimBrodowski FWIW most UNIX tools I use do not support input value encryption, and CLI argument encryption is definitely not a de facto feature of command line tools if you ask me. I am not a security expert but what you are describing is a universal issue with CLI tools and exactly why passing sensitive values as command line argument is frowned upon by some security-minded folks I asked.

Would you mind providing a few examples of the tools that support this and elaborate what specifically you would like to see implemented in this issue?

[michaelklishin]

Two options for "secure configuration of users at runtime" are already available and mentioned above. Breaking the list of arguments and behavior that has been around for some 12 years sounds like a complete overkill.

How do we reliably determine if the tool is invoked non-interactively? Relying on an environment variable like Debian tools do is a confusing solution to the user. We have years of evidence of that.

I am not convinced that this is a "very little effort" kind of change. Too many open ended questions, too many environments would potentially affected.

Shared hosting environments should consider using containers that provide a reasonable degree of isolation for this case.

[KimBrodowski]

Like passwd? This is how you can change a user's password on basically any Unix-like system:

echo -e "password\npassword" | passwd accountname

This is NOT about input value encryption. You might think at first that this will leak the password due to echo being run and visible in the process list, however this is not the case since echo is a shell builtin. Similarly other programs can write to the passwd's processes STDIN to avoid leaking the password.

This behaviour is implemented by essentially almost every program that may receive a password including applications like chpasswd or mysql for example.

[KimBrodowski]

I don't see BC break issues either. You can add an option to specify that the password should be read from STDIN for example or you could simply check if the password parameter is missing in which case the command would not have worked correctly in the past anyway.

[michaelklishin]

Making passwords optional for the few commands that accept them and reading values from standard input sounds reasonable. We can add a global --non-interactive switch that would fail argument validation instead of falling back to stdin.

[michaelklishin]

Superseded by #365 with a more specific description.