Lightning: Avoid leaking bitcoin auth secrets to other users

[jonasnick]

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.

[darosior]

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.

[vasild]

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:

       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.

[ZmnSCPxj]

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