There are three types of (systemd) services that should not start
by default (in every VM):

- those generating some sensitive (=not intended to be shared) data
(tor, ssh server, some database servers?)

- those generating potentially unwanted/unexpected network traffic
(tor, IPv6 tunneling software, VPN services, avahi, ...) It isn't only
about potentially harmful actions (like connecting to tor directly, in
some censored regions), but also about wasting network resources -
especially important on mobile connection.

- generally unneeded services in most VMs - just for saving resources
(RAM, at least) - like bluetoothd, crond, upowerd, smartd, acpid, ...
not all of them are easily removable, because of dependencies

The wider Debian upstream problem here is that Debian enables services
for installed packages by default; and that these packages/services are
not 'Qubes aware', not 'Qubes friendly' or perhaps better more
generically speaking not 'root image sharing friendly'. [open for better
terminology]

Perhaps a drastic solution would be required. Configure somehow that all
installed packages will not start their services by default. Only start
services on a whitelist / opt-in basis. This is not thought through. I
guess this could lead to some issues. And also confusion. But then the
documentation and implementation could be a lot more generic.

As opposed by an opt-in blacklist (using qvm-service). For example let's
say the ssh service was added to such a blacklist. Then the user would
have to do something like the following.

vm settings -> services -> type 'ssh' press enter -> press 'plus'

Which isn't obvious at all. Would require documentation. Would be a
usability issue. And such blacklists would never be complete so it would
only be a partial solution, workaround.

Given the situation that Debian puts us in - enabling not root image
sharing friendly services by default... What is the best, most generic
solution that Qubes can do?

Cheers,
Patrick

Credits. Parts of the above text was written my Marek and modified by me.

Source:
https://github.com/QubesOS/qubes-issues/issues/1625

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

On Wed, Mar 09, 2016 at 09:11:24PM +0000, Patrick Schleizer wrote:
> There are three types of (systemd) services that should not start
> by default (in every VM):
>
> - those generating some sensitive (=not intended to be shared) data
> (tor, ssh server, some database servers?)

IMHO this should be handled regardless of service being enabled or
disabled. bind-directories[1] is some solution for it. Not enabling such
services by default is only limiting damages, not a real solution.

> - those generating potentially unwanted/unexpected network traffic
> (tor, IPv6 tunneling software, VPN services, avahi, ...) It isn't only
> about potentially harmful actions (like connecting to tor directly, in
> some censored regions), but also about wasting network resources -
> especially important on mobile connection.
>
> - generally unneeded services in most VMs - just for saving resources
> (RAM, at least) - like bluetoothd, crond, upowerd, smartd, acpid, ...
> not all of them are easily removable, because of dependencies
>
> The wider Debian upstream problem here is that Debian enables services
> for installed packages by default; and that these packages/services are
> not 'Qubes aware', not 'Qubes friendly' or perhaps better more
> generically speaking not 'root image sharing friendly'. [open for better
> terminology]
>
> Perhaps a drastic solution would be required. Configure somehow that all
> installed packages will not start their services by default. Only start
> services on a whitelist / opt-in basis. This is not thought through. I
> guess this could lead to some issues. And also confusion. But then the
> documentation and implementation could be a lot more generic.

This is how Fedora behaves by default. But on the other hand, Debian
users would expect that installing package is enough to enable the
service...

And as you've said, may lead to some issues.

> As opposed by an opt-in blacklist (using qvm-service). For example let's
> say the ssh service was added to such a blacklist. Then the user would
> have to do something like the following.
>
> vm settings -> services -> type 'ssh' press enter -> press 'plus'

The "type 'ssh'" part could be somehow improved by inventing
mechanism to retrieve available options. It would be huge UX improvement
over the current state, but not sure if good enough.

> Which isn't obvious at all. Would require documentation. Would be a
> usability issue. And such blacklists would never be complete so it would
> only be a partial solution, workaround.

You're right.

> Given the situation that Debian puts us in - enabling not root image
> sharing friendly services by default... What is the best, most generic
> solution that Qubes can do?

Maybe we can try to reuse Fedora solution? There are two files:
1. /lib/systemd/system-preset/99-default-disable.preset, with just
"disable *"
2. /lib/systemd/system-preset/90-default.preset, with a long list of
exceptions from that "disable *". 71 entries.

This will requires some amount of work - some services are named
differently in Debian, some are not included in Fedora etc. But may be a
good starting point. Probably for Qubes case, this list of exceptions
will be even smaller.

[1] https://github.com/marmarek/qubes-core-agent-linux/pull/58

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

iQEcBAEBCAAGBQJW4KDKAAoJENuP0xzK19cs+EkH/RoEsPYKCE63JiXQikM08va0
mCX8BvrdeKfoCq7HlJ6qhuATXlVQHYr0OntTecvVC7H60jGgt25pG+3pQVRKwK4F
ANAHeat8Fqq4zQ+Ku8mwRFNtYuB/x5Y6zaUPnGezcdWxJ8lTKRczMObn+v7H9iEE
O1+AHELEXrLzV6ty/KzVXkATiXOIgtOMJ1eokqKp3LOMn58tFRTYu3ak8aZXzabV
B402ych4Au26MzUcLoWu1Btvp0+xGcNsFS6NZgW6lXadb/r9KU/KL+l+BicztUTn
KZL2Y24HxjZbOZDz0yq1QnQVdmxG0nrH1oY+2HJVQBN00oQUZHxoOFtjMqX2TUw=
=ux2U
-----END PGP SIGNATURE-----