Custom qrexec services

[Jean-Philippe Ouellet]

From https://github.com/QubesOS/qubes-issues/issues/910#issuecomment-275872140
(here to not pollute that issue)

@marmarek wrote:
> BTW I'm curious how many people have custom qrexec services ;) On one of my machines I have 15 of them.


I have at least the following (not all are finished or enabled):

1. requesting port forwarding (with separate policies for different
arguments to denote different ports)

2. requesting USB device passthrough (arg to specify device)

3. requesting VM be created from particular template with particular
RPM installed (to test in clean envs)

4. requesting ssh session from VM with no netvm (mitigates
http://nastytrap.ru:25 issue described by @rootkovska in
https://groups.google.com/d/topic/qubes-devel/niMbDhS_nWI/discussion)

5. render html (like qubes.PdfConvert, and allowed from any)

6. excel-to-csv

7. create hvm w/ particular iso, particular xen cfg, & point
stdin/stdout at console device (from trusted dev vm, for WIP
OpenBSD-in-qubes work)

8. WIP qubes.Filecopy equivalent which does not require the VM to be
running (encrypts the file with a key only known to the dest VM &
stores in staging area for dest VM to retrieve later). Goal is to
safely allow transferring data to VMs with encrypted private.img while
in a physical location where you do not want to type that VM's
passphrase.

9. giving me a serial console without passing through the whole FTDI
device at USB level (for safety, but also works around some issues
when reattaching)

10. killing jtagd & reloading a driver, because dumbly broken tools
are dumbly broken

11. queuing stuff to print

12. start ssh session via sshd -i (inetd mode) (used because i can
multiplex multiple things (shells, scp, etc.) over a single ssh
session, which is convenient in the case of '$dispvm' targets (because
you don't know the name of the just-started VM to specify multiple RPC
calls to it), so in some cases it's less hacky than trying to automate
lots of things over a single qubes.VMShell to a dispvm)

and several more

[Andrew]

Jean-Philippe Ouellet:

Cool!

Great list, and great ideas. It would be nice if generally useful
services like some of these could be included in the repos.

I use a few custom qrexec services myself.

One in particular is designed to act as a socat bridge between a VM
("tor-proxy") hosting a "HidServAuthorizeClient" Tor hidden service on
one side, and a control panel interface on a VM ("host") hosting
software which must be connected to the clearnet on the other side.

The control panel port is firewalled off on "host" and so is
inaccessible over the clearnet. However, incoming connections to
"tor-proxy" (i.e. to the hidden service) launch a qrexec request to
"host", which sets up a socat bridge.

This is probably not a good idea for applications with many new
connections, as the overhead from the Qubes RPC calls for every
connection must be pretty extreme in this context. However, serving Tor
hidden services via a qrexec link to a VM with no networking might be a
neat way to reduce risk of exploitation. Bonus points for using
per-connection disposable VMs and MirageOS unikernels!

Andrew

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sat, Jan 28, 2017 at 05:55:14PM -0500, Jean-Philippe Ouellet wrote:
> From https://github.com/QubesOS/qubes-issues/issues/910#issuecomment-275872140
> (here to not pollute that issue)
>
> @marmarek wrote:
> > BTW I'm curious how many people have custom qrexec services ;) On one of my machines I have 15 of them.
>
>
> I have at least the following (not all are finished or enabled):

So, if we're listing them, here are few of mine:

1. write USB - _unidirectional_ service to write an fs image into USB
stick (service into USB VM)

2. update local apt/yum repository[1] - get packages just uploaded via
qubes.Filecopy and expose them to LAN as yum/apt repo

3. inter-VM git connection[1]

4. send SMS - use built-in modem to send a SMS (using ModemManager d-bus
API) - currently both destination number and text are inside of pipe,
but I consider putting the number into service argument (to allow some
VM to send SMSes only to selected numbers)

5. all those defined in qubes-builder[2], recently published details in [3]

6. (WIP) trigger build in response to github notification (notification
received in one VM, then send a simple signal "something have changed"
to build VM(s) - those VMs will fetch appropriate git repositories (with
signed tags verification), and check if any new package needs to be
built.

7. activate screenlocker - this service is launched when I unplug
yubikey from USB VM (USB VM->dom0, without any data inside the pipe)

8. Send wake-on-lan signal to other machine (service into netvm)


In context of the #910 ticket, here are those where I have multiple
target domains with "allow" rule:

- qubes.Filecopy - I have various scripts to automate my workflow, for
example:
- build rpm package
- qubes.Filecopy it to a VM running repository exposed to my LAN
- run another service to update metadata on that repository (see
service 2)
or this:
- get a build log(s)
- qubes.Filecopy it to another VM with gist tool installed[4], and
limited github API key configured
- launch another service to upload those file to gist
or this:
- build a kernel + initrd
- qubes.Filecopy it to a VM with tftpserver - there
~/QubesIncoming is exposed into LAN using tftp (and my DHCP server
points there to look for PXE files)
In all the above cases, a source VM have multiple "allow" rules to
different destination VMs. In fact on this system the final line of
qubes.Filecopy policy is "$anyvm $anyvm deny", not "ask" ;)

- inter-vm git access - this allows me to push code into different
build/test environment - for example I have different VM to build
some preliminary PoC code, different VM to build test templates (not
using DispVM there, to not rebuild everything each time), etc

- service in point 6 will need to notify _multiple_ build VMs when some
notify arrive - for example to build all Fedora and Debian packages
(those are different build environments)

[1] https://www.qubes-os.org/doc/development-workflow/
[2] https://github.com/QubesOS/qubes-builder/tree/master/rpc-services
[3] https://github.com/QubesOS/qubes-infrastructure
[4] https://github.com/defunkt/gist

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYjU2mAAoJENuP0xzK19csR4wH/0xHbXH6K6QksHe7e8Gxj4ky
a79M1I/Yhq8av4PZvAWSP2WnUomKU2VH9/KSle2GekXIVahpjH3ieVvvsgEFyWJc
5CW0/a0Aq3fLM4rXcsU7R/0YQtfjnu1OgmVQa3CbFTaLFArcyATxD8ODMSfdvtHH
5fFPFiBCplLM3pFIm57hp0+CpqE4fYOonsPsXeBdD9EorhwqyFh9Vbnyx9JbhKFA
1hZ9yBCgM6Hd4AhvUH2zj6bcxfRINHDJ4EYikiBjvAzYIgQq3cxqGhZNKK6k+h9D
ERatifySW6HeKwGXPTHqerxApP131MlucZxIm6sKVsum6nUQs0b72lY12cJjncs=
=nFoR
-----END PGP SIGNATURE-----

[Jean-Philippe Ouellet]

On Sat, Jan 28, 2017 at 9:04 PM, Marek Marczykowski-Górecki
<marm...@invisiblethingslab.com> wrote:
> 1. write USB - _unidirectional_ service to write an fs image into USB
> stick (service into USB VM)

I like this idea (mostly got tired of ... | qvm-run -p sys-usb 'dd
of=/dev/sda') and wrote my own. [1]

Not unidirectional, mine passes back the hashes of reading back what
it just wrote (more to detect failing media than for security). Also
allows the device name to be controlled with argument-specific policy.

[1]: https://gist.github.com/jpouellet/abe5cf438267afffc851a1a11d8be8f0