Deploy additional AdminVM/make Dom0 manageable through onion hidden service to permit trusted 3rd party remote support

[tlaurion]

Hey @SkypLabs

I'm wondering if you are interested in joining forces to create additional recipes? Your project's persona mostly represents the "developer" one, but it would be interesting to develop others. And be able to deploy them remotely, if needed (organization scenario, remote support needs, etc).

This issue proposes a solution to easily deploy salt recipes in a sepearated AdminVM, in managed mode, permitting to deploy persona's needed customizations, being manageable only by that AdminVM.

The idea here would be:

• [ ] Create an additional AdminVM with SSH server in it, having networking from sys-whonix and create required policies under dom0 for this new AdminVM to be able to create and manage qubes created by it.
• [ ] Create a unique hidden onion service under sys-whonix pointing to AminVM IP:22, restart tor and export hidden onion name and it's public token to dom0 console. (or better: sys-whonix widget, showing user created hidden services in a GUI, see below)

QubesOS servers or laptop daily drivers could be remotely managed for support by a whonix-ws qube from anywhere in the world, under condition that the AdminVM is started prior to the user support request, and that the support team's sys-whonix knows the remote hidden onion domain name and it's public token, exported previously!

This way, managing AdminVM could permit remote management without jeopardizing security, run needed custom salt recipes for additional personas from a remote support team, etc.

Dom0 would need to run this base salt recipe once after a clean QubesOS install (by the support team), and the other AdminVM would be used to create all other qubes that it can manage after if the user needs it, remotely.

That would fit organization needs and user support needs, and permit different persona deployments, after default installation.

Problem and mitigation: One problem still persists for organizational deployments though.

• One way is for the admin to visit user's owned computer (LUKS formatted computer, unlocked by user password. It cannot just be changed), and install the AdminVM recipe under the user eye's supervision.
• Another would be to deploy cryptsetup-reencrypt in dom0 in first stage install of QubesOS. Stage 1 could also set default LUKS encryption passphrase in anaconda.cfg installation file and set a default QubesOS username and password, install this AdminVM, and in stage 2, require the user to change default username and password and reencrypt LUKS with user's passphrase. (PoC needed. @marmarek, thoughts?). Librem QubesOS's OEM install disk implemented a workaround to ask for user's LUKS password to encrypt disk on stage1 and install QubesOS from there, but that solution is limited in the current proposition scope, permitting complete user's ownership of the laptop, but not permitting remote support and persona's deployments. EDIT: PoC here.

Further steps needed from QubesOS/Whonix: @adrelanos @marmarek @vic @mfc: For organizations, it would be amazing if this hidden service, pointing to the AdminVM, could be displayed to the user in a sys-whonix widget, showing their existence and even permit the renewal of those hidden onion names (delete the hidden services directory content and restarting tor and showing hostname content would do) show their associated public token would permitting the user to see/activate/deactivate them on demand. That would greatly facilitate QubesOS deployments in organizations and facilitate user's support needs and general UX. Even give an additional opportunity to generate revenue for QubesOS or subcontractors or support freelancers, or even AccessNow helplines, who knows.

[SkypLabs]

Hey @tlaurion.

Thanks for reaching me out about your project. Sorry for my late response, I've been crazy busy with work recently.

I like the idea of creating different recipes for different flavours :) Actually, I've already had the idea of using a hidden onion service to synchronise/back up data with remote storage services in a secure way but didn't have the time to implement it.

I would like to continue my work on my formula first before working on other ones, specially for sorting out everything. I was investigating on the use of SPM to properly package this formula and why not splitting it up into smaller ones to get something more modular. I also would be interested in writing a Salt formula to create a Kali Linux template as it is not officially supported by the Qubes OS project at the moment.

However, as I said, I am interested in your suggestion of collaboration. We could work together on the design and technical considerations of the new formulas while, on my side, continuing my work on this one. What do you think?

[marmarek]

I have evaluated SPM usage in the past, but failed to find reliable way to a) authenticate packages b) convince spm to work on a local repository in dom0, without network access (qubes-dom0-update like solution). But I might be also missing something obvious.

[tlaurion]

@marmarek : cryptsetup-reencrypt implemented under Heads reencrypts 240GB drive in 25 minutes with directio.

[tlaurion]

@adrelanos @marmarek

For organizations, it would be amazing if this hidden service, pointing to the AdminVM, could be displayed to the user in a sys-whonix widget, showing their existence and even permit the renewal of those hidden onion names (delete the hidden services directory content and restarting tor and showing hostname content would do) show their associated public token would permitting the user to see/activate/deactivate them on demand.

Any widget suggestion that depends on file processing that this idea should be based on to make onion hidden services visible/easy to edit to end users, both for authenticated client/server authenticated configurations?

[adrelanos]

A Qubes salt command making it easy to remote administrate a remote dom0 over Tor onion would be really really cool. (Pierces through any NAT, even works if both are behind NAT even on mobile networks.)

I did that before.

Similar to https://www.whonix.org/wiki/Dev/Qubes#ssh_into_Qubes_dom0 but not documented fully anywhere I think.

Perhaps make remote dom0 support as simple as / similar to OninoShare?

Two choices:

• Qubes start menu -> sys-whonix -> persistent remote support (would always start, also after reboot, until "Stop" pressed
• Qubes start menu -> sys-whonix -> one time remote support (would start only once)

Two buttons.

• Start
• Stop

After start, a new field opens with information to be copied to the one who should gain remote access.

• It should should contain the commands required for accessing an authenticated onion service using HiddenServiceVersion 3 (the one just started) to be run on remote onion service. The command supposed to be pasted into sys-whonix.
• It should also contain the SSH / VNC line supposed to be pasted in anon-whonix to access the remote dom0.

That's a program to invented and contributed to Whonix?

[adrelanos]

Tor onion service ideally gets created using Tor control protocol. Can be restored after reboot. Tor control protocol communications based. No Tor config file modifications which are still clunky [...]. Like OnionShare does. (Called "ephemeral" Tor hidden services but these are not necessarily ephemeral.)

[tlaurion]

@adrelanos : you would prefer direct access to dom0 vs another remote-mgmt-AdminVM that can only manage it's own deployed templates and created VMs?

[tlaurion]

@marmarek : can an additional remote-mgmt-AdminVM deploy salt recipes directly or this is limited to dom0?

[SkypLabs]

I have evaluated SPM usage in the past, but failed to find reliable way to a) authenticate packages b) convince spm to work on a local repository in dom0, without network access (qubes-dom0-update like solution). But I might be also missing something obvious.

@marmarek: I haven't used SPM so far and I don't know if there is a proper way to use it with Qubes OS. If I find such a way, I won't miss to tell you.

[SkypLabs]

@adrelanos : you would prefer direct access to dom0 vs another remote-mgmt-AdminVM that can only manage it's own deployed templates and created VMs?

@tlaurion: Using an AdminVM would be way better. The less code you run in dom0, the more secure your system would be.

@marmarek : can an additional remote-mgmt-AdminVM deploy salt recipes directly or this is limited to dom0?

@tlaurion: I think it's not possible at the moment according to the Qubes OS Admin API documentation. The AdminVM would talk to dom0 through qrexec calls which don't include a way to open a shell on the remote AppVM and it's exactly what qubesctl does (see here).

[adrelanos]

tlaurion:

@adrelanos : you would prefer direct access to dom0 vs another remote-mgmt-AdminVM that can only manage it's own deployed templates and created VMs?

I am not into implementation details.

My wish is to give remote support to remote machines which I manage. I want to upgrade dom0 there, reboot and maybe other dom0 fixes (yum software sources) and whatnot.

Ideally I could explain how to set up remote access to dom0 by breaking it down to "a single dom0 console command".

[tlaurion]

I also would be interested in writing a Salt formula to create a Kali Linux template as it is not officially supported by the Qubes OS project at the moment.

@SkypLabs : You might want to look into this and adapt: https://github.com/Nekroze/qubes-salt/tree/master/vms/kali

[marmarek]

@marmarek : can an additional remote-mgmt-AdminVM deploy salt recipes directly or this is limited to dom0?

Depending on what those recipes do. Generally everything that qvm-* tools do is possible from mgmt-vm too (given appropriate policy), so all the basic management stuff should work. But not things that require direct dom0 access like creating files there, installing dom0 packages etc. BTW we are working on managing qrexec policy from MgmtVM. As @SkypLabs already pointed out, using qubesctl to manage things inside VMs isn't possible right now from non-dom0. Given the nature of recipes (ability to adjust arbitrary configuration, execute commands etc), such possibility would effectively give MgmtVM full access to that VMs (including everything based on templates managed by it). Which may not be a bad thing in general, but it needs to be a conscious decision. And very few pieces are missing to make it reality.

[tlaurion]

@unman?

[tlaurion]

The goal would be to automate this

[tlaurion]

Note to self: look into this https://github.com/fepitre/qubes-mgmt-salt-qubes-server

[tlaurion]

Released over https://www.whonix.org/wiki/Remote_Administration#Qubes_-_SSH_or_VNC_into_Qubes_dom0. You can close this issue, thanks to NlNet support for Accessible Security support!

[mfc]

Released over https://www.whonix.org/wiki/Remote_Administration#Qubes_-_SSH_or_VNC_into_Qubes_dom0. You can close this issue, thanks to NlNet support for Accessible Security support!

amazing, nice work! it would be great to include a reference to this in the Qubes documentation when you have the chance, in case someone is first looking there.

[adrelanos]

For reference only: https://github.com/QubesOS/qubes-issues/issues/6364

[SkypLabs]

Awesome! Thanks for letting me know.

I'm closing this issue.