making networking configurable (routing/gw: y/n, dns: y/n)

[Joonas]

Hi,

all my VMs are behind a non-routing proxyvm.

As an additional safeguard to prevent accidential attempts to route
packets to the internet (ip_forward is already 0, FORWARD is set to
DROP) I'd like to change the network configuration, namely remove the
default gateway and the DNS server entries (/etc/resolv.conf).

As far as I've seen routing and /etc/resolv.conf is setup via
/usr/lib/qubes/setup-ip

but it doesn't seem to be configurable. Is that correct or did I miss
anything?
(I could modify that file but that would only last until the next update
occurs.)

Would you mind adding a configuration possibility to allow networked VMs
that do not have a default gw and an empty /etc/resolv.conf?

thanks,
Joonas

[Marek Marczykowski-Górecki]

The easiest way to disable network in a VM is just set its "netvm"
property to "none". This way the VM will have no network interface at
all so it wouldn't be possible to leak network traffic because of some
firewall configuration bug. You can do the same to ProxyVM or even
create NetVM without any network device attached.

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

[Joonas]

(ML emails don't seem to reach me so I'm replying to your answer directly)

Setting the netvm to 'none' would disable networking completely, that is
not my intention. The VMs still need to reach the proxyvm (a proxy is
running there), but VMs should not have any default gw or dns server.

[cprise]

So you don't want the appVMs (or all VMs) to have a default gateway or dns server? Or just the proxyVM to not have them?

[Joonas]

(my mailprovider still seems to have issues, currently reading your
replies via google groups webinterface ;)

replying to cprise:

Actually that shouldn't matter.
The possibility to disable default gw and dns should ideally not be
limited to any specific VM type. I will use it for multiple VM types.

[Marek Marczykowski-Górecki]

How about setting netvm to 'none' for ProxyVM? Or do you want to still have
internet access directly from ProxyVM? In that case, unsetting defgw
isn't the most efficient thing to do - if you want prevent VM from
accessing the network (directly) you shouldn't do it in a way that VM
can undo on its own. The right place is the iptables in your ProxyVM.

You can also set netvm to 'none' in your VMs, then connect to ProxyVM
using qrexec services instead of IP. This way you more reliable way to
filter access, but will be somehow more complicated to setup. You can
use socat to pass network connection through qrexec (one socat to listen
on some port and pass the data to qrexec service, and the other one to
receive the data and pass to preconfigured destination).

[Joonas]

Marek Marczykowski-Górecki:

> How about setting netvm to 'none' for ProxyVM?

That is not my intention either since the proxyvm needs to reach its
upstream.

> Or do you want to still have
> internet access directly from ProxyVM? In that case, unsetting defgw
> isn't the most efficient thing to do - if you want prevent VM from
> accessing the network (directly) you shouldn't do it in a way that VM
> can undo on its own.

No worries about that, the downstream appvm can't 'undo' the
'no-routed-internet' policy without owning it's proxyvm first.

Back to my initial question:

Would you mind adding a configuration possibility to allow networked VMs
that do not have a default gw and an empty /etc/resolv.conf?

Doesn't seem like a very exotic feature request, or does it?

thanks,
Joonas

> You can also set netvm to 'none' in your VMs, then connect to ProxyVM
> using qrexec services instead of IP. This way you more reliable way to
> filter access, but will be somehow more complicated to setup. You can
> use socat to pass network connection through qrexec (one socat to listen
> on some port and pass the data to qrexec service, and the other one to
> receive the data and pass to preconfigured destination).

Yes, I saw the
"How to make proxy for individual tcp connection from networkless VM"
URL to Igor's ML posts in the qubes doc, but I would only use that once
it would become a standard Qubes OS qrexec service.

[Franz]

On Thu, Jan 22, 2015 at 10:30 AM, Joonas <joonas....@openmailbox.org> wrote:

Marek Marczykowski-Górecki:
> How about setting netvm to 'none' for ProxyVM?

That is not my intention either since the proxyvm needs to reach its
upstream.

> Or do you want to still have
> internet access directly from ProxyVM? In that case, unsetting defgw
> isn't the most efficient thing to do - if you want prevent VM from
> accessing the network (directly) you shouldn't do it in a way that VM
> can undo on its own.

No worries about that, the downstream appvm can't 'undo' the
'no-routed-internet' policy without owning it's proxyvm first.

Back to my initial question:
Would you mind adding a configuration possibility to allow networked VMs
that do not have a default gw and an empty /etc/resolv.conf?

Doesn't seem like a very exotic feature request, or does it?

It seems to me that nobody really understood why you want this feature and, most important, which is the compelling use case that would justify the effort to implement it.  Well may be I am the only one who did not understand :-)

thanks,
Joonas




> You can also set netvm to 'none' in your VMs, then connect to ProxyVM
> using qrexec services instead of IP. This way you more reliable way to
> filter access, but will be somehow more complicated to setup. You can
> use socat to pass network connection through qrexec (one socat to listen
> on some port and pass the data to qrexec service, and the other one to
> receive the data and pass to preconfigured destination).

Yes, I saw the
"How to make proxy for individual tcp connection from networkless VM"
URL to Igor's ML posts in the qubes doc, but I would only use that once
it would become a standard Qubes OS qrexec service.

--
You received this message because you are subscribed to the Google Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/54C0ED7B.7050207%40openmailbox.org.

For more options, visit https://groups.google.com/d/optout.

[cprise]

On 01/22/15 08:31, Franz wrote:

On Thu, Jan 22, 2015 at 10:30 AM, Joonas <joonas....@openmailbox.org> wrote:

Marek Marczykowski-Górecki:
> How about setting netvm to 'none' for ProxyVM?

That is not my intention either since the proxyvm needs to reach its
upstream.

> Or do you want to still have
> internet access directly from ProxyVM? In that case, unsetting defgw
> isn't the most efficient thing to do - if you want prevent VM from
> accessing the network (directly) you shouldn't do it in a way that VM
> can undo on its own.

No worries about that, the downstream appvm can't 'undo' the
'no-routed-internet' policy without owning it's proxyvm first.

Back to my initial question:
Would you mind adding a configuration possibility to allow networked VMs
that do not have a default gw and an empty /etc/resolv.conf?

Doesn't seem like a very exotic feature request, or does it?

It seems to me that nobody really understood why you want this feature and, most important, which is the compelling use case that would justify the effort to implement it.  Well may be I am the only one who did not understand :-)

I think I understand the 'why'... He wants to be able to create unusual networks of VMs that don't fit the use cases of a typical PC -- with its automatic routing to an upstream provider -- even if some other parts of his system do behave and access the Internet normally.

This seems like a reasonable request to make: Easy defaults often need to have options for exceptions.

Of course, such a power user could always setup another machine running Virtual Box and configure their Linux clients however they wish... but why take that freedom away from Qubes in the first place?

My suggestion to Joonas is to add this issue to the bug tracker.

[Joonas]

Franz:

>> Back to my initial question:
>> > Would you mind adding a configuration possibility to allow networked VMs
>> > that do not have a default gw and an empty /etc/resolv.conf?
>> >
>> > Doesn't seem like a very exotic feature request, or does it?
>> >
>> >
> It seems to me that nobody really understood why you want this feature and,
> most important, which is the compelling use case that would justify the
> effort to implement it.

The use case is rather simple:

Have an additional safeguard to avoid accidentially leaking packets even
in case the upstream proxyvm's config (the one that usually ensures
proxy obedience) gets messed up (i.e. by a broken update).
(but there are certainly other use cases for non-routed networking I guess)


I assumed that an implementation would not be to big of an effort?

add two additional boolean qvm-prefs, something like
setdefaultgw = true/false
setdns = true/false
(both default to true)
Expose them to the VM via xenstore.


Add two additional if blocks to /usr/lib/qubes/setup-ip (if that is
indeed the case where it needs to go?)

9a10,13
>
> setdefaultgw=`$XENSTORE_READ setdefaultgw 2> /dev/null`
> setdns=`$XENSTORE_READ setdns 2> /dev/null`
>
17c21,23
< /sbin/route add default gw $gateway
---
> if [ x$setdefaultgw == 'xtrue' ]; then
> /sbin/route add default gw $gateway
> fi
20,21c26,29
< echo "nameserver $gateway" > /etc/resolv.conf
< echo "nameserver $secondary_dns" >> /etc/resolv.conf
---
> if [ x$setdns == 'xtrue' ]; then
> echo "nameserver $gateway" > /etc/resolv.conf
> echo "nameserver $secondary_dns" >> /etc/resolv.conf
> fi
47c55
< if [ "x$network" != "x" ]; then
---
> if [ "x$network" != "x" ] && [ x$setdns == "xtrue" ]; then



I assume /var/run/qubes-service/network-manager is only used for netvms,
so I should not care about line 40 I guess.

[Marek Marczykowski-Górecki]

It seems you are the only one interested in such a feature ;)
So... you can implement this and send a patch to qubes-devel ML. I
suggest doing this as qvm-service[1], so no change in dom0 would be
needed. Remember to make those services enabled by default[2], or name
them like "disable-defgw".

[1] https://wiki.qubes-os.org/wiki/QubesService
[2] http://git.qubes-os.org/?p=marmarek/core-agent-linux.git;a=blob;f=vm-systemd/qubes-sysinit.sh;h=54f71386d5cbcb66102ab5a6339d2aa1cbf26998;hb=refs/heads/release2#l3

[Joonas]

> It seems you are the only one interested in such a feature ;)
> So... you can implement this and send a patch to qubes-devel ML. I
> suggest doing this as qvm-service[1], so no change in dom0 would be
> needed.

I guess using a service implies simply reverting parts of the setup-ip
script by invoking
route del default
rm /etc/resolv.conf

that is the somewhat unclean way I've been trying to avoid, because
there should not be a default gateway at any given time (no race between
packets and a del-defgw service?).

Or did you have something else in mind?

[Marek Marczykowski-Górecki]

That usage is just an example. You can simply use qvm-service as an
on/off switch of some functionality in VM (take a look at qvm-service
manual - for example yum-proxy-setup is such a "service").

You can change qubes-ip to just check for existence of
/var/run/qubes-service/SOME_NAME before setting default route and DNS
addresses.