RFC: Local name services and VMs

[Achim Patzner]

Hi!


Am I the only one who would like an integrated name service management
for local services that will be provisioned at the time of VM creation
(e. g. if you create a machine "builder" its assigned IP address could
be added to the locally running dnsmasq on the NetVM)?



Achim

[Alex]

This somehow is against the principle of "isolation" between the
AppVM... But I can understand that, from a developer point of view, this
may be helpful - if, for example, you develop web-apps and assign a
web-app per AppVM to host.

Yet, Qubes OS is designed for workstations, and it may be argued that
developer workstations may host the services they are developing. I
think, IMHO, that this is wrong, and may lead to unnecessary complexity
in dealing with the subtleties of the application working on the
developer's workstation but not in production. I would recommend to test
them on the work AppVM, and then complete testing in a staging environment.

I myself built a low-cost staging machine, with proxmox and several VMs
with a centos template: my production machines are typical VPSs with
centos, so the differences between staging and production are minimal.

Beyond the developer point of view, do you think there would be other
examples that would benefit from having Qubes AppVMs mutually visible?
(thus needing an auto-registering name resolution system?)

--
Alex

[Marek Marczykowski-Górecki]

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

On Sat, Jul 02, 2016 at 02:30:15PM +0200, Alex wrote:
> On 07/02/2016 02:19 PM, Achim Patzner wrote:
> > Hi!
> >
> >
> > Am I the only one who would like an integrated name service management
> > for local services that will be provisioned at the time of VM creation
> > (e. g. if you create a machine "builder" its assigned IP address could
> > be added to the locally running dnsmasq on the NetVM)?
> This somehow is against the principle of "isolation" between the
> AppVM... But I can understand that, from a developer point of view, this
> may be helpful - if, for example, you develop web-apps and assign a
> web-app per AppVM to host.
>
> Yet, Qubes OS is designed for workstations, and it may be argued that
> developer workstations may host the services they are developing. I
> think, IMHO, that this is wrong, and may lead to unnecessary complexity
> in dealing with the subtleties of the application working on the
> developer's workstation but not in production. I would recommend to test
> them on the work AppVM, and then complete testing in a staging environment.

I use somehow similar workflow - have code in one VM, then compile and
test in other VM. To transfer between those VMs I use git connection.
Take a look here for details:
https://www.qubes-os.org/doc/development-workflow/#tocAnchor-1-1-3

Also another possibility is to send already compiled artifacts to
testing VM, then trigger a script which will deploy whatever landed in
`~/QubesIncoming/development-vm`. Some variant of it is described here:
https://www.qubes-os.org/doc/development-workflow/#tocAnchor-1-1-4

> I myself built a low-cost staging machine, with proxmox and several VMs
> with a centos template: my production machines are typical VPSs with
> centos, so the differences between staging and production are minimal.
>
> Beyond the developer point of view, do you think there would be other
> examples that would benefit from having Qubes AppVMs mutually visible?
> (thus needing an auto-registering name resolution system?)

Generally, if your workflow assume frequent communication between two
VMs, it may mean you do something wrong - those VMs should either not
communicate at all, or be a single VM. But there may be also valid use
cases - for example for uni-directional communication (you send
something to less trusted VM and never retrieve it back).
Also it's better to use qrexec services for that, to reduce attack surface
(all the networking stack, plus enforce policy using dom0, instead of
potentially compromised netvm or firewallvm).

It should be easy to hook any TCP connection into qrexec using socat.

Something like this (untested):

source VM: launch this somewhere (/rw/config/rc.local?)

socat TCP-LISTEN:4444,fork EXEC:"qrexec-client-vm target-vm my-tcp-service"

target VM: /usr/local/etc/qubes-rpc/my-tcp-service (this is stored in /rw):

socat STDIO TCP:localhost:4444

dom0: /etc/qubes-rpc/policy/my-tcp-service

source-vm target-vm allow


@Andrew do you think we should have this documented somewhere? Or maybe
even some tooling to ease such setups?
But first it would good to actually test above instruction ;)

- --
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

iQEcBAEBCAAGBQJXeVlvAAoJENuP0xzK19cssnYH/0ZwyhJlnM/8stSimn8Yoadt
1tBdpbEmA2ksHgbKNdpMhuOJthcmwL/sdPSqoPPyqzDfaWICsSWpi3zWyKSLNhzm
Emd8ub398xSm9TLOqpcOWhc4hLSfSE2QwUAhWvqq6V8zthsv9UePRYNL8Vd5QSpy
zQe/8pRhQUMF1TRPrQEIdXnNI5Q2wVQEBSHV91Gu6LtCYLQAkzSGRRggroM0NUxt
4IKygVsm9b29UVwMQ8Uj4Jqby7hEi/4fV+zQgQ1Wue//8enQl3CR8S2lNu/54yhh
XcHLv4KUpCHoD5YQfDEiN4xssKbmUV4rgKbN2wVcUvQmmUhNDkd/UvyFcp/crfU=
=geL0
-----END PGP SIGNATURE-----

[Achim Patzner]

Hm. I never received the original answer, so...

Am 03.07.2016 um 20:29 schrieb Marek Marczykowski-Górecki:
> On Sat, Jul 02, 2016 at 02:30:15PM +0200, Alex wrote:
>> On 07/02/2016 02:19 PM, Achim Patzner wrote:
>>> Am I the only one who would like an integrated name service management
>>> for local services that will be provisioned at the time of VM creation
>>> (e. g. if you create a machine "builder" its assigned IP address could
>>> be added to the locally running dnsmasq on the NetVM)?
>> This somehow is against the principle of "isolation" between the
>> AppVM...

What about the aesthetic reason of not having to look at naked IP
addresses in the outpit of traceroute?

To be honest: I've missed more than once that a VM was not using the
firewall VM I intended it to use and I guess seeing a symbolic name in
the output would improve pattern recognition in human brains.

And my next request will probably be a tool moving the entire address
range Qubes is using somewhere else as 10.137/16 seems to be quite
contested real estate.


Achim

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2016-07-03 11:29, Marek Marczykowski-Górecki wrote:
> It should be easy to hook any TCP connection into qrexec using
> socat.
>
> Something like this (untested):
>
> source VM: launch this somewhere (/rw/config/rc.local?)
>
> socat TCP-LISTEN:4444,fork EXEC:"qrexec-client-vm target-vm
> my-tcp-service"
>
> target VM: /usr/local/etc/qubes-rpc/my-tcp-service (this is stored
> in /rw):
>
> socat STDIO TCP:localhost:4444
>
> dom0: /etc/qubes-rpc/policy/my-tcp-service
>
> source-vm target-vm allow
>
>
> @Andrew do you think we should have this documented somewhere? Or
> maybe even some tooling to ease such setups? But first it would
> good to actually test above instruction ;)
>

Indeed. Created an issue for it here:

https://github.com/QubesOS/qubes-issues/issues/2148

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXecC1AAoJENtN07w5UDAwbcoQAJ1UNxMyfVSQsnCdxrD4wwWG
M9eP929D1Wfh3023KlyObqs2mtOgSNKs1bvsyAebKWdJGDnxkzgZRfjnEXHt2myT
h718lz66d+e3SgJly49fOJ3cnKtcdMnVWY6bBv9w6pIOHo3MqzHkgrDzM7++2b0l
Qu2GwIjsID7Kxo8wUUxor2cNo+ZOsCfecP9B+nGM3cn1aTb25jAvL8YRvTDLVF1S
0t09Guy/7HWVIbhYO7qus4Vi7Z3PKSxHTyE8K8fXQyqYYtHkP/pIlnZ3LMqqeoqG
XKaWF9H1ugVSZWOgE2zsWnVSytNLemX3B6nKmQHkcYe42d9pu2pjs1NN8PpPaNNH
2oKdwqFQjlhl9DoRW1DR32ofSvTleqLO3ufesFJ7SFEWvpgcPCvLBU26aKMQqsZz
2VdVFJwx/QvrE7ZxhfO9Xf6BHfPOY/K+ym9JPKleBe1XAl7X9L+IAf4fOkNl4wDz
COh4Ljn2N+uId/HvO+kyV1sn16saNyCz8ml1p5qP6+nhOswkDkDWl7Qt9f067zLg
zGDaPit2c/uJletL3YtlCGPxvFs9o9QNYtFklYzZ2mCpqAky8QDdwQ09FYZ52cSB
Xt9nqpgwzBOCXwONhB/OMyQRVfLTKStmFJSkdrUm+praz0kINTZCorW4VyU8RMYw
QDs/ub6Ujch4lNTwqjzy
=Jcie
-----END PGP SIGNATURE-----