Author Topic: RPC calls access control  (Read 2552 times)

0 Members and 1 Guest are viewing this topic.

Offline wackou

I've been meaning to make the BitShares directory read-protected by default on UNIX-like OS's since October -- https://github.com/BitShares/bitshares/issues/856

And now it's in the develop branch :)

Great, these are the small details that make a big difference (IMO)!

I have also started work on a proxy script here: https://github.com/wackou/bts_proxy
Still not complete, and doesn't do any filtering yet, but I had to deal with my 2nd daughter being born (first day of the year was fun! :) )
This should be done in a couple of days, next week at most, at which point I'll release it officially. I made it as a separate project so that it's small, easy to review, and people actually trust it to do what it advertises (without backdoors for the NSA, etc.)

I think I'll also write a quick guide on how to setup a delegate securely on a server, should help most people that know how to run a script but are not completely up to snuff on security (which should help the entire network indirectly)
Please vote for witness wackou! More info at http://digitalgaia.io

Offline theoretical

I've been meaning to make the BitShares directory read-protected by default on UNIX-like OS's since October -- https://github.com/BitShares/bitshares/issues/856

And now it's in the develop branch :)
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline theoretical

(as you rightly pointed) the config.json file needs to be read-protected with its own user account, which makes it less immediate to setup

Speak for yourself.  I've been running the BitShares client in its own user account since the beginning.

Which reminds me, I've been meaning to make the BitShares directory read-protected by default on UNIX-like OS's since October -- https://github.com/BitShares/bitshares/issues/856
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline wackou

You could probably implement this in ~5 lines of Python by just running a proxy that forwards RPC's in the whitelist of allowed calls and blocks unlisted RPC methods.

Keep in mind you have to protect your config.json, for example by giving the Bitshares client its own user account and setting UNIX permissions (e.g. chmod 600) on config.json.  Otherwise a rogue script could just read the RPC username and password directly from the config file.

Now that you say it, this indeed seems like the best option. My first thought was to get this as close as possible to the client, so that it's easier to configure/setup and that there is as little attack surface as possible, but then (as you rightly pointed) the config.json file needs to be read-protected with its own user account, which makes it less immediate to setup and then the overhead of setting up a python RPC proxy doesn't seem so big anymore. (I use the standard location of the config.json myself in the bts_tools for convenience to get the RPC user/password without having to type them :-[, so I couldn't limit the tools themselves by setting up access rights in that file...)

I might whip up such in proxy script in the next few days, stay tuned...
Please vote for witness wackou! More info at http://digitalgaia.io

Offline theoretical

You could probably implement this in ~5 lines of Python by just running a proxy that forwards RPC's in the whitelist of allowed calls and blocks unlisted RPC methods.

Keep in mind you have to protect your config.json, for example by giving the Bitshares client its own user account and setting UNIX permissions (e.g. chmod 600) on config.json.  Otherwise a rogue script could just read the RPC username and password directly from the config file.
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline wackou

Please vote for witness wackou! More info at http://digitalgaia.io

Offline wackou

The "wallet_enabled" config property should get you 90% of the way there. Do you need more granular control than "can access funds" ?

Thanks, I didn't know about this one. I think more granular would be better, though, for instance let's say I want to give access to my wallet to a script that publishes feeds (quite common ;) ), but I don't really want that script to have unrestricted access to my funds, only the wallet_publish_feed method is required.
Please vote for witness wackou! More info at http://digitalgaia.io

Offline bytemaster

Create a github ticket for this idea.  It is low hanging fruit and something that a bounty could probably cover...

It should take at most 1 day to implement.  But of course I cannot do it and the other devs are booked.   Good option for someone to get their feet wet.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
The "wallet_enabled" config property should get you 90% of the way there. Do you need more granular control than "can access funds" ?
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline wackou

There's a thought (and a question) I had a while back, but that came back to mind today as I was thinking about all the things that could be built upon the BitShares platform (happens to me a lot :P), and which is the following:

would it be a lot of work to implement some sort of access control to the RPC calls to the client?

I originally had this question when using a small RPC proxy to the client to be able to do some Ajax calls from a webpage, however I didn't feel very comfortable that this proxy had unrestricted access to my client (which was also running my delegate at the time).

There are also the tools that I'm working on, which (understandably so) people don't necessarily feel comfortable running (unless properly reviewed before) as it could easily steal their private keys if having access to an unlocked wallet.

Something like that would be nice in the config.json file

Code: [Select]
"rpc": {
    "enable": true,
    "users": [
        {
            "rpc_user": "web_client",
            "rpc_password": "password1",
            "rpc_methods_allowed": ["get_info", "about", "blockchain_get_blocks"],
        },
        {
            "rpc_user": "bts_tools",
            "rpc_password": "password2",
            "rpc_methods_allowed": ["get_info", "blockchain_get_delegate_slot_records", "wallet_publish_feeds"],
        }
    ],
    "httpd_endpoint": "127.0.0.1:5678",
}

maybe also having the "rpc_methods_forbidden" property would be nice, which would allow things like:

Code: [Select]
"rpc_methods_allowed": ["*"],
"rpc_methods_forbidden": ["wallet_dump_private_key"]

although it's generally better to always whitelist instead of blacklisting methods, so we could probably do with only "rpc_methods_allowed" at the beginning.

I know that there are other priorities right now in the development of the wallet, but if this is not too much work, I think it'd be very nice to have (probably this also could help for integration in gateways, as it would allow to have a python/php/... interface to the client which has limited access to what the client can do)
Please vote for witness wackou! More info at http://digitalgaia.io