[PATCH] new network configuration possibilities: set-default-route, set-dns-server (as qvm-service)

[Joonas Lehtonen]

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

Hi,

I've modified /usr/lib/qubes/setup-ip to allow users to opt-out of
default routing and prevent setting the DNS servers (/etc/resolv.conf) -
giving users more flexibility to configure their VM's networking [1].

Patch is against v2.1.51

I've tested it on the following VM types (using the default and
minimal fedora templates):
- - TemplateVM
- - AppVM
- - DispVM
- - ProxyVM (with and without qubes-firewall/qubes-network enabled)

Description from the man page:

set-default-route
Default: enabled

Sets the default route for networking. Disabling this service
will prevent the creation of the default route, but the VM will
still be able to reach it's direct neighbors. The functionality
is implemented in /usr/lib/qubes/setup-ip.

set-dns-server
Default: enabled

Creates the appropriate nameserver entries in /etc/resolv.conf.
Disabling this service will result in an empty /etc/resolv.conf.
The functionality is implemented in /usr/lib/qubes/setup-ip.


If this change is acceptable to you I would be happy to test rpms via
the testing repo before they get to current (if something goes wrong
here users could potentially loose network connectivity).

regards,
Joonas


[1] https://groups.google.com/d/msg/qubes-users/4OnYA0Jog08/ncnn8KEh6mIJ

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUw5ZVAAoJENGIB/ssoMC2dRsQALNiD2UI0lZ0snePnOSFTlvE
mVjt6Hg2soeGVWfMKm4GArlcfRY+S8DiJna8Wwg3PHSPGmqg3y0M/LuAlFuLh4Hr
vW1h5D20Ebn1q4lrsL1EonjqTNaf2HhNU98u173PdcvXNq0HcumBYd29UOHfSwWh
Zrq3iBha/YqKxgEmSLKqR3tkEtH24z0bZGFFNPGXtYFfekD2k1nbfZ7ZpXsAAcn3
XZfX3H36IvGQhjT5+c5o6tvE6d1qR8RWanU5WqZGMTJRHrxaEhOZEpCIf9ktwVuD
EQ9UIfuk7XCR8B0VxAaqP++h8flczu03551tGnadbIvri//V0NdnsVkFJ/LbPscw
ZGcCDDZkb4fhJLB6g8/MpiSJE19XHNsGozDKf/TvQNp2YxgTlnEidjPkohykgX1q
qFl3IYbJ+ZbME0YylJPw6/olvAGln3v+uNTZHcCX+AOjuwt06vfhnbrDq5C7bBq9
g+/n1lMjAKUT/uNmEbqagAW9GR0k0sxXhNkGfRWdHOYtfr0sjInj91IQdiJEqhhx
2w7DiiL39G9I+/nC3zp5Idj/oasQpV7JNz1rofUx/ApIPhvNIKoUq+C+V/BwFOyT
ItQFbiFeC1RLRaS8/OGqNQlyd+5Mg71/D5lL041tnJJU6YRcZwOk4NLDzqPGMmkt
oVCw1+DQnCzu4ldgvliV
=Y3br
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

On Sat, Jan 24, 2015 at 12:55:50PM +0000, Joonas Lehtonen wrote:
> Hi,
>
> I've modified /usr/lib/qubes/setup-ip to allow users to opt-out of
> default routing and prevent setting the DNS servers (/etc/resolv.conf) -
> giving users more flexibility to configure their VM's networking [1].
>
> Patch is against v2.1.51

I've applied the patch, but for the next time, please read this:
https://wiki.qubes-os.org/wiki/DevelFaq#Q:HowdoIsubmitapatch
If you don't want to setup git environment, please at least use "diff
-u".

> I've tested it on the following VM types (using the default and
> minimal fedora templates):

> - TemplateVM
> - AppVM
> - DispVM

> - ProxyVM (with and without qubes-firewall/qubes-network enabled)

(...)

> If this change is acceptable to you I would be happy to test rpms via
> the testing repo before they get to current (if something goes wrong
> here users could potentially loose network connectivity).

I've made a few adjustment and committed. New package(s)
qubes-core-vm*-2.1.52 are available in qubes-vm-r2-unstable repo.

> [1] https://groups.google.com/d/msg/qubes-users/4OnYA0Jog08/ncnn8KEh6mIJ

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

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

Marek Marczykowski-Górecki:

> I've made a few adjustment and committed. New package(s)
> qubes-core-vm*-2.1.52 are available in qubes-vm-r2-unstable repo.

Unfortunately it doesn't (always) work as expected. I guess there is a
race condition.

Until now I simply assumed that qubes-sysinit.sh will *always* be done
(with setting up service files) before setup-ip is invoked, I guess
that assumption is wrong.

setup-ip is invoked via
- - udev-qubes-network.rules
- - qubes-misc-post.service
- - qubes-core
- - other?

qubes-sysinit.sh is invoked via qubes-sysinit.service


-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUx96uAAoJENGIB/ssoMC2BQIP/0cwqPvNZSaph/Ze06n2iAhV
hyWCp8bC7gN4LNdFQFzBdCuZj85Sviac29meJTYJZTmRm98YrKPBX+Wl0oYEf412
b8qDZTWTFfGaZPNucNpP2XsjMsVJ0vOlXNr7EuQqCPpUUyhHgH2ayrJD3QOQ6/p3
sKfz2Fds3OXk3/eJVF3UN1Z/cn4ioZW7mMstC6inKwzHnn/KOYSqNpgaXG26wxe+
jUApmoLAaXBXVNcsqjyesLgXtvzYDJnNj1Rf76086+4XyiiTjmwFpOFquW46bAjO
cUF0NSBPdLOuaV6y+fR0fckNhQcniXjPvSP+u73WIs+Mjmw/MnREeIZWpNH86n6D
py+49X9ozTgJ8PV5zUmYbc7rlhkPFca3jcYOIqZGtz8kfTZVsx/C869jZ2RjfQUU
rh7WmooyM9VhNRheLqBwQLpUleBZAVPFIORkhj4kfe/4UuffTBgBA7Y5NM5aVwtF
NLnZe0HFAI6xl9rYWHf+4a8iwL1B60XOBVfkixwCfBr6qR5pAM5mjuTDcwnRL1kC
kmRNyqU/2pBmQ+w/tSVSgrBeM/MwsfrKC9L4KXZ65rC7FIK+9oBPSb8AAe3wYuP/
VHqv0BYN/c4B+iLk+UbrrmyidtbG04kTl+zWAmmXcB92k58du/G9xrTr+zzVtYvZ
hX+DmYGMucU57dASc3ju
=6HNn
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

On Tue, Jan 27, 2015 at 06:53:57PM +0000, Joonas Lehtonen wrote:
> Marek Marczykowski-Górecki:
> > I've made a few adjustment and committed. New package(s)
> > qubes-core-vm*-2.1.52 are available in qubes-vm-r2-unstable repo.
>
> Unfortunately it doesn't (always) work as expected. I guess there is a
> race condition.
>
> Until now I simply assumed that qubes-sysinit.sh will *always* be done
> (with setting up service files) before setup-ip is invoked, I guess
> that assumption is wrong.
>
> setup-ip is invoked via

> - udev-qubes-network.rules

I think this is the place called before qubes-sysinit.

> - qubes-misc-post.service
> - qubes-core

> - other?
>
> qubes-sysinit.sh is invoked via qubes-sysinit.service

Perhaps the right way to solve the problem is to read qubes-service/*
xenstore entries in setup-ip, instead of relying on
/var/run/qubes-service/* files?

[Marek Marczykowski-Górecki]

On Tue, Jan 27, 2015 at 08:00:05PM +0100, Marek Marczykowski-Górecki wrote:
> On Tue, Jan 27, 2015 at 06:53:57PM +0000, Joonas Lehtonen wrote:
> > Marek Marczykowski-Górecki:
> > > I've made a few adjustment and committed. New package(s)
> > > qubes-core-vm*-2.1.52 are available in qubes-vm-r2-unstable repo.
> >
> > Unfortunately it doesn't (always) work as expected. I guess there is a
> > race condition.
> >
> > Until now I simply assumed that qubes-sysinit.sh will *always* be done
> > (with setting up service files) before setup-ip is invoked, I guess
> > that assumption is wrong.
> >
> > setup-ip is invoked via
> > - udev-qubes-network.rules
>
> I think this is the place called before qubes-sysinit.
>
> > - qubes-misc-post.service
> > - qubes-core
> > - other?
> >
> > qubes-sysinit.sh is invoked via qubes-sysinit.service
>
> Perhaps the right way to solve the problem is to read qubes-service/*
> xenstore entries in setup-ip, instead of relying on
> /var/run/qubes-service/* files?

BTW I think it is a good idea to change "set-default-route" and
"set-dns-server" to "disable-default-route" and "disable-dns-server".
That way if anything goes wrong, the user will not end up with broken
network (and can't update the package to the fixed one).

[Joonas Lehtonen]

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

Marek Marczykowski-Górecki:

> Perhaps the right way to solve the problem is to read
> qubes-service/* xenstore entries in setup-ip, instead of relying
> on /var/run/qubes-service/* files?

If one should not/can not rely on the files under
/var/run/qubes-service when creating new qvm-services, then the entire
qvm-service design is flawed, no?
Or the other way around: What are the files in /var/run/qubes-service
good for if I can't trust that to be setup when the check for these
files is performed?

There needs to be a clear indication when it is safe to rely on these
files. Maybe do a
touch /var/run/qubes-service/DONE
at the end of qubes-sysinit.sh?
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUx+jIAAoJENGIB/ssoMC2bbEQALITsWNp8BdxaDnHfP0sILmI
41CR5MnLgySu37FXwGG7/r3NdTCLHWF/q3bIj4wWNGItZV4/1szEdH5ZUWkCyGWu
wCgFcBqZbLEsqisSyL6gcpCr7MU0N0hW2BGRug8F4p7oaDYlYFzl1hRBNbpXF7PG
Yvgjy+BGDi0M9FcxxApWX9J4Iluskko8wq7NfmBVLWjsm6TuNTfMPegs9YCEkCcn
fe7btJ9anAorxeNnnEe5BJKOxKykUtifybVR2acGeVhOVWXl54bNhcTaxW9SrkfB
Oi1piDO4xoNGstT0xclg52jw0e691u6wTZSbzm82KLdX3nFMUjTlEwu05TGc0OGg
gu2rUZxyOoGIMZz/ei5LD+Wg7BpcUWOhXDcuoI++hCqDCho3oFY/Ug1INBLjtvz1
yciIDHuVF7iZUAV//TGvqPI4EgyrryNZDPSoxu143uptRTXroYRrjPnzhJ1hi5mo
Ch+9oOGIwhgMR0rdOn8KzI+Mr6RvHQncicnbeOdn+z+cEAUQ8ndW1/oe0rGJ2B34
IvLXHwMY6Wq8CnaOZ9hOAhv8ChDVzIyz0DVZ9nIXCzqgtnkPLyu31yGHtUNNsQav
FvK2NFbPhNr9MTJ0v1m9TnD+/zgWTzXNm4pZUmrZOVgBqGe3h3eGhDDt0IRc4Mic
gQkNUSGK4UwZDdjNgfve
=3lTo
-----END PGP SIGNATURE-----

[Joonas Lehtonen]

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

Joonas Lehtonen:

> There needs to be a clear indication when it is safe to rely on
> these files. Maybe do a touch /var/run/qubes-service/DONE at the
> end of qubes-sysinit.sh?

That is probably a bad idea as well, because how do you make sure that
file gets deleted on shutdown? You can not make sure your VM is
shutdown cleanly all the time.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUx+nnAAoJENGIB/ssoMC2e/EP/iQw0F+uAHVE5SPHqVn84G05
K3RlJb/30FDB9HTBMVR4fXFbwtHM+dyVwtI9Gkj+eovn+rb7+trObWW7sD36StWB
NWWgQB/Fh2k0LMLSKRRRGSYW8r6TPfsZCLKCTk7G2qzBRIOLvUZmysBmO3sYCe93
Olm0ruGXPVjVOGF88lJf9KisKW3uvh+LvZweBkWee8UuZ881PHixNd2aWNB1YFn6
O8otNGdMKo4EhNYcWW46OodPrfAcpBl4R5BBdhKMZtdO5CD9OLa8xAnfzPmQMYkD
mvZN+qaFwPX/sLSNrlbAO1gdyHuwRaj90fRUvF2Y8oRzE12xImsbDMAJQjcLSVL7
Iv80nojhMYrHFvHJ2vWzjBu1IM59ZDH3m8LnVXhniAfAV4TXPgFARCUSRBZQ+0eV
XvvS/994bqCS/sK8d8ky0jVEu9m/w+jaBZNdO0pam+yjwdM64m2Fgh7Mm2UeajOm
+7CDcEC4DqbxZ45tQKPjVrsfCn7l9bhIxrytgAeyOvulAlpdDmjx/5+l094vn5xx
GqoiLEfI/KpyEhb49ca0H+7JoFv6HQJ4KGxHGC9RC4XUWPHp8ZxY8d69oVLLcm9R
9BWgzUPBEz3fcjj5be5YIakmGsbwdvRKMoZUzwgfeurHycSDmn2sqbrei5klLJJO
fvL1MxxMOSi25riPo/8J
=UlWL
-----END PGP SIGNATURE-----

[Joonas Lehtonen]

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

Marek Marczykowski-Górecki:

> Perhaps the right way to solve the problem is to read
> qubes-service/* xenstore entries in setup-ip, instead of relying
> on /var/run/qubes-service/* files?

Is it safe to assume that xenstore reads are "race condition free" or
do I have to make sure that I perform the read after X has been completed?
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUx+rWAAoJENGIB/ssoMC2p7kP/iKWhn97jFVashPalz+NX5o+
UaSYPIYln4lDRsMsRAsFOKTV92dIVfthXN8Ekh2XNqN/GPJL0+t6tPwhXK5Rrxpa
zl4qWC8zBcE7abIDcCvq3PKfx4qe3q7SyvxpUc2SyMIWESPyf1ckLmAg4O3xg8aB
4HwCoWMktJJFc69A2EPvRq6jtt81jppmxyOXkIJf5N/En5DbfAmJ6vt2d79pHVEg
NZSh6nOdNZ0tmU6yA9Tra/j0lhktm+K+lSYzVjC6Cz2CNNDxXM3DXILM6KE7GVno
7kLAnq5EAMPoTUwde0jtsdkPRWB11t/Qo7TB03MFnE0NaeGIIwDeNQ7meoVS0fmB
Lo1ywAvb+mYG0FwK+o5JdjyIDaxUqkssqbbINzQv6cEGgW2gjZ3bGZWF4He6WmH6
FwSECbvfYLWXitwmZj93dYR2BOEay/v11hJVZ37RgQgmai+ACQeaYiWubBpsiOt4
S7wxeppHFvPQ/M0K1tfTO7wBuqDpSyv7jNCWt/L/eeEChn2WeSvH1b0EQEZVHvVc
awnI8VIn4Q2ihTh24TuGZ86ShMeBGxdzjxiYWqFBsLLPBPmREccEXdHvvK39yPyF
oijOlMeSv367cVjL6gGJjgSX8sbemlsGMWHywRAOu3ghnyszILg4qA5D3mNtTwqK
/2zG9CM7rrrXx4n6pPtf
=b2Bh
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

On Tue, Jan 27, 2015 at 07:36:40PM +0000, Joonas Lehtonen wrote:
> Marek Marczykowski-Górecki:
> > Perhaps the right way to solve the problem is to read
> > qubes-service/* xenstore entries in setup-ip, instead of relying
> > on /var/run/qubes-service/* files?
>
> If one should not/can not rely on the files under
> /var/run/qubes-service when creating new qvm-services, then the entire
> qvm-service design is flawed, no?
> Or the other way around: What are the files in /var/run/qubes-service
> good for if I can't trust that to be setup when the check for these
> files is performed?
>
> There needs to be a clear indication when it is safe to rely on these
> files. Maybe do a
> touch /var/run/qubes-service/DONE
> at the end of qubes-sysinit.sh?

In case of services it is guaranteed that qubes-sysinit.service is
started before any normal service (it is part of sysinit.target and
every service have implicit After=sysinit.target).

But in case of udev rules there is no such guarantee...

On Tue, Jan 27, 2015 at 07:45:26PM +0000, Joonas Lehtonen wrote:
> Marek Marczykowski-Górecki:
> > Perhaps the right way to solve the problem is to read
> > qubes-service/* xenstore entries in setup-ip, instead of relying
> > on /var/run/qubes-service/* files?
>

> Is it safe to assume that xenstore reads are "race condition free" or
> do I have to make sure that I perform the read after X has been
> completed?

Yes, those xenstore entries are create before VM gets started.

[Marek Marczykowski-Górecki]

On Tue, Jan 27, 2015 at 07:41:28PM +0000, Joonas Lehtonen wrote:
> Joonas Lehtonen:
> > There needs to be a clear indication when it is safe to rely on
> > these files. Maybe do a touch /var/run/qubes-service/DONE at the
> > end of qubes-sysinit.sh?
>
> That is probably a bad idea as well, because how do you make sure that
> file gets deleted on shutdown? You can not make sure your VM is
> shutdown cleanly all the time.

/var/run is on tmpfs, so yes - the files wont survive restart.

[Joonas Lehtonen]

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

patch* is against 2.1.52


changes:

- - resolves a race condition by no longer relying
on /var/run/qubes-service/* files

- - inverse logic (disable vs. enable)

- - qubes-sysinit.sh + qubes-core changes are no longer required and can
be reverted (due to the inverse logic)



































*) sorry for not using 'diff -u' yet, haven't figured out how to
prevent the inclusion of the timestamp
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUx/tZAAoJENGIB/ssoMC2j5kP/3HsLwy+xcNM9qGVem4twVpB
p9iZ6GJWVibx1jyKKs+P85kbbMl/QljeJF5F6DJwplLCsElTMZtDWIGQ9TCK0Voe
xpw+RxRVXAUW/nAVny2M48dmmFWf68/PoK1UJAlp1kNOMrSx3v5ugwT5dkDEqSu2
h6s5Gj4arKdWLBjHfrjisT8coa5dRYSVA9EKCQOfNkZCleV/pUh8hW7LvbdWtAlm
8NfU7p1GVjizwbdGPMHATh+/XIIHp/k3kbOcoIb/CZleeCck7fM2eckZZDKizENl
B9YZnTP13lX5Im2dkl30NEkxKS05s0kqU65RT3xoUJT5EQZs1KPdCmH87g8OdgeK
lw4fE/KOHBMAuAzpBqazYuYDc6/bHN9Qwlh+/zmcLXU02ogoLFd84gCSmFIxyTiR
478U0DiAZCD8Vnu7XIOxBGGUAO4W8Pdy86c29HNxBuhPhSE2MpIhuEK6w0EdoJog
WSd4p7v/73kftVA5BVfq4P6FxhfhiknqOatOhFdygW8qiEWgxcw6kbiq5rIednMI
HcJqNtSO3NAkQNr4jkcRpMdIHg6Fk2Ac7JnED7ATPOeGh3vYrNKGewJeQ4npVAnI
KwIlCaBbxBFuNprUM53smWvHWZtubNeg8kTu7RrV/eNQIEep1LmkaQexuGW/FG90
2K7EdebUOOdGHC3MyPmL
=hvgq
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

On Tue, Jan 27, 2015 at 08:55:53PM +0000, Joonas Lehtonen wrote:
> patch* is against 2.1.52
>
>
> changes:
>
> - resolves a race condition by no longer relying
> on /var/run/qubes-service/* files
>
> - inverse logic (disable vs. enable)
>
> - qubes-sysinit.sh + qubes-core changes are no longer required and can
> be reverted (due to the inverse logic)

Applied, qubes-core-vm-*-2.1.53 uploaded to unstable repo. Those package
should also fix filecopy problem on grsec kernel, although I haven't
tested such combination.