Explicitly states that RPC credentials grant full administrative access to the node and filesystem resources accessible by bitcoind. Adds a new section in JSON-RPC-interface.md to address issue #32274 by documenting that providing RPC credentials to untrusted clients
reopened #32424
P.S. I've tried to somehow squash all the commits from the previous pr but accidentally closed the pr and had no idea how to return back, therefore created a new pr, I'm really sorry for the inconvenience
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--006a51241073e994b41acfe9ec718e94-->
For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33196.
<!--021abf342d371248e50ceaed478a90ca-->
See the guideline for information on the review process.
| Type | Reviewers |
|---|---|
| ACK | janb84, sedited |
| Stale ACK | davidgumberg |
If your review is incorrectly listed, please copy-paste <code><!--meta-tag:bot-skip--></code> into the comment that the bot should ignore.
<!--5faf32d7da4f0f540f40219e4f7537a3-->
ACK 433954b6a5bd7480f7e05e58eafeac1dc6dfae7c
This PR adds information about security considerations when using RPC clients. Although bitcoin-core has done everything to minimise the risks of using RPC, it's good to inform the user of the risks and the extra security precautions the user can take.
Informing the public about security risks and methods to mitigate them demonstrates responsible stewardship; therefore, I support this pull request.
ACK 433954b
134 | + separate user accounts with restricted permissions) rather than relying solely on 135 | + RPC access controls. While Bitcoin Core provides the `-rpcwhitelist` option to 136 | + restrict which RPC commands specific users can access, and `-rpcwhitelistdefault` 137 | + to control the default behavior for users without explicit whitelists, these should 138 | + not be considered robust security boundaries, as users with access to certain 139 | + commands may still be able to exploit functionality in unexpected ways.
The first few sentences seem largely redundant with the rest of the docs (see few paragraphs of "Security" section, and "Secure authentication". However, the bit about whitelisting RPC commands for specific users seems helpful.
I think the existing docs make it pretty clear that other processes/users with access to the machine can comprise the node, but I think what is not obvious in the existing docs is that the other direction is true as well, someone with RPC access can probably compromise the machine the bitcoind node is running on.
re ACK 938312d7a6dcf06cb401a16651e80320f36ee4db
Still think its a valuable addition. It introduces a clearer and stronger trust-boundary statement that is not explicitly documented elsewhere. To me, users should be informed about this so that they do not compromise their node's security unknowingly.
Yes the paragraph is long and somewhat repetitive but it communicates the implications clearly, so that non (deeply) technical people should also understand the consequences of their actions in this.
Most relevant overlaps with this change:
docs/JSON-RPC-interface.md:L118-119:
<details> Any program on your computer with access to the file system and local network can obtain this level of access. </details> This sentence covers the whole idea, but short and it's easy to skip/overlook.
docs/JSON-RPC-interface.md:L144-163
<details> You may optionally allow other computers to remotely control Bitcoin Core by setting the `rpcallowip` and `rpcbind` configuration parameters. These settings are only meant for enabling connections over secure private networks or connections that have been otherwise secured (e.g. using a VPN or port forwarding with SSH or stunnel). **Do not enable RPC connections over the public Internet.** Although Bitcoin Core's RPC interface does use authentication, it does not use encryption, so your login credentials are sent as clear text that can be read by anyone on your network path. Additionally, the RPC interface has not been hardened to withstand arbitrary Internet traffic, so changing the above settings to expose it to the Internet (even using something like a Tor onion service) could expose you to unconsidered vulnerabilities. See `bitcoind -help` for more information about these settings and other settings described in this document. </details> Closest overlap in intent. It already warns about RPC network exposure and safe binding behavior. But remains to vague about the security risks IMO.
docs/init.md:L24
<details> Running bitcoind as a daemon does not require any manual configuration. You may set the `rpcauth` setting in the `bitcoin.conf` configuration file to override the default behaviour of using a special cookie for authentication.
This password does not have to be remembered or typed as it is mostly used as a fixed token that bitcoind and client programs read from the configuration file, however it is recommended that a strong and secure password be used as this password is security critical to securing the wallet should the wallet be enabled.
If bitcoind is run with the "-server" flag (set by default), and no rpcpassword is set, it will use a special cookie file for authentication. The cookie is generated with random content when the daemon starts, and deleted when it exits. Read access to this file controls who can access it through RPC.
By default the cookie is stored in the data directory, but its location can be
overridden with the option -rpccookiefile. Default file permissions for the
cookie are "owner" (i.e. user read/writeable) via default application-wide file
umask of 0077, but these can be overridden with the -rpccookieperms option.
This allows for running bitcoind without having to do any manual configuration.
conf, pid, and wallet accept relative paths which are interpreted as
relative to the data directory. wallet only supports relative paths.
To generate an example configuration file that describes the configuration settings, see contrib/devtools/README.md.
</details> Covers how RPC authentication is set up (rpcauth, cookie auth, rpcpassword fallback), but no explicit mention about security considerations. Personally would even say that a reference to the RPC documentation would be valuable.
ACK 938312d7a6dcf06cb401a16651e80320f36ee4db