RPC permissions

[Sjors]

I've been using Lightning Charge a fair bit, but I don't like that it has full control over the lightning node. It would be nice to have a way to limit RPC permissions, for instance just the ability to create and check the status of invoices.

One approach could be to have to multiple --rpc-file like arguments, each with their own set of permissions. The default RPC socket is owned by the user/group that launched the process, and permissions are set to 600. The additional RPC sockets should allowing specifying the group owner and set permission to 660. That way e.g. a system could have a group lightning_rpc_invoices whose users can use the RPC to create invoices.

Specifically this group should have access to: help, decodepay, getinfo, invoice, listinvoices, delinvoice (?), waitanyinvoice (?), waitinvoice, .

The above would go a long way. Some additional ideas:

• individual RPC users can "own" invoices. With the example of Lightning Charge that would allow it to delete its own invoices, while not being able to mess with - or even see - invoices it doesn't own. That would suggest creating user (in stead of group) specific RPC interfaces, or moving to an authentication model more like what bitcoind uses.

• a group that can manage channels, but not spend funds: help, decodepay, getinfo, connect, listnodes, listpeers, disconnect, getroute, listchannels, fundchannel, close, newaddr

• a group that can withdraw funds (on chain and off chain): same as channel manager, plus sendpay, waitsendpay, pay, withdraw. Although that's a lot of permissions, at least it can't sabotage the node by physically reading the database from disk and broadcasting illegal states. It could be additionally constrained through an address (and destination node public key) whitelist.

[ZmnSCPxj]

Now it seems to me that, in true lightningd spirit of splitting things out to multiple daemons, we could implement this as a separate daemon, lightning_capabilityd. This would read a configuration file, which could be something like:

[*]
allow = help, getinfo, newaddr, decodepay

[/var/lightning-charge-rpc]
umask = 666
allow = invoice, listinvoices, delinvoice, waitanyinvoice, waitinvoice

[/var/lightning-cli-rpc]
allow = *

The capabilityd would read the configuration file, then set up the RPCs as specified, with each RPC having specified filtered methods. capabilityd would also filter the result of help so that only the RPCs allowed get help entries.

Then you would set up your tools (Lightning Charge, whatsoever) to use the specific RPCs.

[cdecker]

Please, let's not add yet another daemon. The capabilities enforcement is rather easy to implement (we have similar capabilities for hsmd already implemented), and I'd probably do a simple split into read-only and read-write RPC calls as an intermediate step.

[rustyrussell]

You could, and should, write your own daemon to do this!

[Sjors]

In that case having a "how to write your own RPC permission daemon for non-veteran kernel devs.md" would be useful :-)

[Sjors]

Does the new plugin system make an RPC permission system easier? Is anyone working on that? For example it would be really nice if the user / group running Spark (cc @shesek) could be restricted to only paying and creating invoices, perhaps even with a spending limit per time window.

[cdecker]

I'm currently playing with the idea of having a --plugin-runner command line argument that is prepended to the plugin execve call. This could allow the creation of a plugin firewall that can do arbitrary things with the plugins it controls (containerize them, run them as separate users, filter RPC commands, ...). Does that sounds like something that could be useful?

[ZmnSCPxj]

This could allow the creation of a plugin firewall that can do arbitrary things with the plugins it controls (containerize them, run them as separate users, filter RPC commands, ...). Does that sounds like something that could be useful?

Yes.

[rustyrussell]

I would like to do this: write a small wrapper which proxies the JSON RPC uses runes to limit what commands can be run (like commando!). But there's no real point, UNLESS you also sandbox the plugin using some method.