Monero Wallet/Daemon Isolation with Qubes + Whonix

Community Guides
5

Yeah, the daemon is all synced and good. It’s once I fire up wallet-cli the socat messages pops and wallet reports no connectivity with the daemon.

6

Now I’ve been able to get back to my Qubes lappy, it turns out my issue was a simple brain-fart on my part.

The edit to /rw/config/rc.local in 4.2 had not been saved (duh!). Once I’d sorted that, everything fires up.

Thankfully, I can now stand by my original post that the github guide is a valid method.

I very much hope you’ve been able to get through the obstacle you experienced, @helge

7

@MrA I wish I could say yes to that. Was kinda hoping you would come with some revelation :slight_smile:
Still at the same point, once I start CLI the socat process on the wallet vm is killed.
If I start it manually I get to the see the errors, which are as the ones stated above.

I don’t know if this is an issue with 4.1 or whats going on here, but I have created and deleted the setup several times to make 100% sure I’m doing each step, but as mentioned, once I try to reach the local socat process it dies.

8

Hi,

Thanks for the Git process, really nice!

I face 2 issues on my side:

  1. how to change the path of the lmdb Monero Database?
  2. when I start GUI in my ws-wallet how do I configure the database to be the monerod because it shows syncing with no block while my lmdb has already few GB (not 100% yet)

Thank you

9

@jKER24qP since you even got to this part I’m curious, what version of QubesOS are you on?

To answer your questions:

  1. you can use the --data-dir /path/to/blockchain in your systemd file (check monerod --help for all options)
  2. You mean it creates a local blockchain on the ws-wallet? If so it haven’t caught the setup and started a local daemon, try with the cli wallet and make sure it are able to connect to the daemon from the monerod-ws.
    Which might in turn mean you have the same issue as me.
10

It seems to be either me thats completly missing something or simply these steps doesn’t work with 4.1 code.
I tried to get my Trezor T working which also rely on the same method of using socat.
Method shown here: https://wiki.trezor.io/Qubes_OS
Same thing happens here, socat dies once the port is accessed.

11

Thanks for the update @helge. Must be like you said - something in 4.1

Mine using the github guide on 4.0.3 is working well.

I have no Trezor to test your thought, unfortunately. I do have a Ledger S, and I came across the ‘How-to: Ledger Hardware Wallet in Qubes’, but I’ve not had the chance to mess with it so far. Plus it looks to be a completely different trip to the Trezor method you point to.

12

Well, got it working, but I don’t understand why this was needed.
I decided to start the daemon with --rpc-bind-ip=0.0.0.0 --confirm-external-bind
Then I was able from the wallet-ws to utilize socat and reach the daemon-srv via localhost:18081.

Since no incoming requests to the daemon is allowed anyhow it’s not a biggie, but still…
Having it listen on all IPs rather than just localhost is a bit meh, and not what I expected.

Did you do this as well @MrA or does it work with the daemon listening on localhost only (as per default) work for you on 4.0.3?

13

@helge

Cool. Definitely something for me to note whenever I move to 4.1.

I’ve not had incoming with the github guide and, like you mention, no biggie. I made no changes to the steps in the guide.

I’ve also upgraded monero to 0.17.1.3 this evening too. Released yesterday, I beleive.

14

I moved the reply on another thread here for cleanness:

For easyness of testing (if someone wanna have a go at it) I’d like to throw in some details.
The issue seem to be that if you have a qube hosting a TCP service on a qube called srv-qube.
Then we got another qube, with no netvm, called client-qube.
The TCP service on srv-qube listens on localhost:18081.

On 4.0.3 it seems to no problem at all using socat (or the new “wrapper” ConnectTCP) and reaching that TCP service calling localhost:18081 on client-qube.
On 4.1 however I was unable to replicate this, what I instead had to do was on srv-qube make the TCP service listen on 0.0.0.0:18081 then use socat or qvm-connect-tcp (same settings/method as 4.0.3) to call localhost:18081 from the client-qube, now I’m reaching the service on srv-qube.

Sorry to hijack the thread @MrA just wanted to throw in some extra info as I had the exact same problem with another service that wasn’t monero (the trezor daemon).
Hopefully if someone else struggle with monero separation or any other networking service in non-netvm enviornment this thread can shed some light.

Very curious myself to know if its just my end or if there is a networking change in the background here =)

15

Not at all :slightly_smiling_face: I think it’s great we can put this all together, and I very much appreciate your input. I’m sure I’m not the only one who will find all this extremely useful when I make a move to 4.1

17

Maybe you should open an issue against Qubes OS 4.1? But then again, maybe not?

It certainly looks like a change in functionality in the 4.1 implementation… but that change may actually be done intentionally, since services that only listen on localhost should only be reachable from the local host or VM???

18

I agree, normally networking wise, anything listening on localhost is meant to be only reached from localhost.
Though in this a bit special case with Qubes it does work to share such a resource between Qubes trouch socat, if your allowing it via dom0.
All guides for cryptocurrency and trezor T hardware wallet setup in qubes rely on exactly this.

So security wise, to me, it sounds very good to have the daemon simply listening on localhost, but trough socat/ConnectTCP we manage to reach it even though.
This can of course be achived by other means, like blocking incoming packets destined for the daemon, but the whole idea behind making the daemon listen on localhost is to avoid any chance of remote RPC calls (which in turn COULD potentially lead to tampering).

So these guides shows how to still keep that security aspect, but at the same time give access to the daemon from the qube, with no netvm, that holds your private keys.

At this stage I’m ok with that as a solution, this whole thing has turned in to a more curiousity case to what actually has changed.
I’ve been at it on 4.1 for a while now to try to use these various cryptocurrency/hardware wallet guides with no success, until I discovered this 0.0.0.0:PORT solution.

19

Does that mean you need to adopt the [file] in the /rw/usrlocal/etc/qubes-rpc/user.monerod in the Monero VM-Doemon to:
socat STDIO TCP:localhost:18081 --rpc-bind-ip=0.0.0.0 --confirm-external-bind or where do you need to add “–rpc-bind-ip=0.0.0.0 --confirm-external-bind”?

I am running Qubes 4.1 and without “–rpc-bind-ip=0.0.0.0 --confirm-external-bind” i get “Error: Couldn’t connect to daemon: 127.0.0.1:18081” in the wallet VM

20

Thank you going to try this now.

Is there anything needed to do when template vms are updated? The time I got it working it stopped after I updated.

21

I haven’t found any issues so far. That includes after updates.

22

UPDATE

For those members who are unfamiliar and find they need to upgrade their isolation to the latest Whonix 16:

Assumptions:

  • You’re upgrading from the Whonix 15 template you have to Whonix 16 released a few days back (rather than installing the isolation from scratch with Whonix 16).
  • You originally used the guide linked in the OP.
  • You’ve already upgraded your Whonix template to 16.
  • You’ve named your Wallet and Daemon VMs as in the guide above.
  • Both these VMs are not running in your Qubes Manager.

In Dom0 terminal

  1. Clone your whonix-ws-16 template:
    qvm-clone whonix-ws-16 whonix-ws-16-monero

  2. Move your wallet and daemon VMs to the clone:
    qvm-prefs monerod-ws template whonix-ws-16-monero

and

qvm-prefs monero-wallet-ws template whonix-ws-16-monero

  1. Complete the section 2.1 to 2.4.

Note:
In 2.2.1 and 2.2.2 change kwrite to nano and once you’ve pasted the script in each of the files, save/close them with CTRL+x.

Fire up your daemon to sync and you should be good to go.

Edit: and while you’re at it, increase the monerod-ws volume to 120Gb

23

I had @helge’s problem as well:

I followed the Qubes documentation for opening a single TCP port to another qube, which ended up working.

Steps:

  1. Follow all the steps linked in the above github guide
  2. Do not add the socat TCP-LISTEN command to /rw/config/rc.local in the wallet VM. Instead, add qvm-connect-tcp ::18081 to rc.local (you can’t have both qvm-connect-tcp and socat bind to the same port, so I choose to forgo socat)
  3. Create a TCP connect policy in dom0: /etc/qubes-rpc/policy/qubes.ConnectTCP:
monero-wallet-ws @default allow,target=monerod-ws
  1. Run qvm-connect-tcp ::18081 in monero-wallet-ws or restart the wallet VM and let rc.local handle it

My monero wallet VM then connected to the monero daemon VM.

Please test this method to see if it works. I’m also not entirely sure why this worked, and what parts of the github guide are strictly necessary to make the qvm-connect-tcp method work. I imagine this would preserve the split-* security model because of the policy because the TCP port is only available to be used from monero-wallet-ws to monerod-ws?

2 Likes
24

Did a fresh install of 4.1rc3 last week and had to do the tcp port like qubes-kernel-5.8 suggested.

Monerod and wallet are showing syncing, how when checking the Active: status of monerod-mainnet it shows as failed “start request repeated too quickly”. Not sure if this is the right thread but not sure what’s going on or how to troubleshoot it.

1 Like
25

I planned to sit down and upgrade in the coming days. Did you find a cause/solution to what you mention?