ElementsProject
Avoid leaking bitcoin auth secrets to other users
On Linux, running ps -e -o args frequently enough will eventually show the bitcoin-cli child process spawned by c-lightning including the RPC authentication arguments. The issue is that by default any user on the system can get the authentication secrets doing that - not just the user the c-lightning and bitcoin-cli processes run as.
I can reliable reproduce this with a fresh c-lightning datadir, --network main and running the following script under a different user:
#!/bin/bash
while :
do
RES=$(ps -e -o args | grep -v grep | grep bitcoin-cli)
N=$(echo "$RES" | wc -l)
if [ "$N" -gt 1 ]; then
echo "$RES"
fi
done
This problem can be mitigated by mounting /proc with the hidepid option. However, process arguments seem to be generally not considered secret. For example, even with hidepid if you run lightningd as a systemd service, other users can see the arguments of bitcoin-cli through systemctl status (H/T @nixbitcoin, see https://github.com/systemd/systemd/issues/16825).
A naive idea for how c-lightning could prevent this is if it created a temporary config file for bitcoin-cli with the authentication secrets and provides the file via the --config argument.
We could also directly use bitcoind JSONRPC interface instead of proxying through bitcoin-cli.. For reference @vasild pointed this out to me while i was coding bcli, but doing this would be a huge refactor.
I think connecting to bitcoind over TCP would be safer, faster (exec(bitcoin-cli) is slow) and less error prone (bitcoin-cli needs to find its own config file).
As a simpler workaround maybe this option of bitcoin-cli can be used:
-stdinrpcpass
Read RPC password from standard input as a single line. When combined
with -stdin, the first line from standard input is used for the
RPC password. When combined with -stdinwalletpassphrase,
-stdinrpcpass consumes the first line, and -stdinwalletpassphrase
consumes the second.
The workaround idea by @vasild seems good.
Possibly another eventual thing to do would be to move the backend from using the RPC interface to using the P2P interface. bitcoind has an atrocious policy regarding RPC stabililty, i.e. "RPC stability, that is some kind of pasta right?", xref. allowhighfees in sendrawtransaction. But bitcoind does have a very rigid policy regarding P2P interface stability, which is "we have to be able to talk to BitCoin Alpha 0.1.0 for Windows if necessary AT ALL COSTS because maybe Satoshi will come online again after his extended vacation".
This problem can be mitigated by mounting /proc with the hidepid option
hidepid does not work anymore with the newer versions of systemd and cgroups v2 (see here). As a result, on modern distributions (such as NixOS 21.05), there is no (known) way to prevent bitcoin auth secrets from leaking to other users. We have a hard time updating the nix-bitcoin project to NixOS 21.05 because nix-bitcoin's promise is that services are decently isolated from each other which isn't the case if c-lightning is enabled.
Would it be possible to prioritize this? The various suggestions in this thread all seem fine to me.
-stdinrpcpass seems like low-hanging fruit that could be implemented quickly and easily, even if a move to the P2P protocol is envisioned for the future.
Please don't break the use of the cookie file for those of us who prefer to use that (more secure) method of authentication. That's already immune to leaky process arguments so long as only authorized users can read the cookie file.
@whitslack how does cookie file authentication work with c-lightning? I can't find any mention of this in the lightningd-config manpage.
how does cookie file authentication work with c-lightning?
@jonasnick: Just don't specify bitcoin-rpcuser and bitcoin-rpcpassword. Then C-Lightning seems to pick up ${bitcoin-datadir}/.cookie automagically.
@whitslack Thank you, I remember. That is not a general solution unfortunately, because cookie authentication prevents using bitcoind's RPC whitelisting capabilities. In nix-bitcoin for example, clightning authenticates to bitcoind as an RPC user that only has access to public RPCs.
@jonasnick: You prompted me to read a little bit about NixOS. Does it really not use PID namespaces to isolate processes owned by different users, given that unprivileged users are allowed to use the package manager to install packages for their own use? In other words, I'm surprised that snooping on bitcoin-cli process arguments is even a possibility in NixOS, given that one user should not be able to see any processes in another user's PID namespace, much less their arguments.
@whitslack sorry but that seems a bit too off topic for this thread. Feel free to contact me at [email protected] or join #nix-bitcoin on liberachat.
Hello everyone,
in #5509 I've tried to pass the RPC password from stdin instead of using an -rpcpassword argument. Could you please take a look and let me know what you think?
