Debian template: disable newly (all) installed services by default

[rootkovska]

The role of a Qubes template is to offer software (i.e. a filesystem with installed software), not to run it!

It might break some security assumptions if all the software user intends to install in a template (which the user might want to use only on few of the AppVMs based on that software) was also made running in all the AppVMs based on that template.

While we do not allow for inter-VM networking between AppVM by default, neither to reach AppVM from the outside world (thanks to default DNAT-based routing), there still might be edge cases where enabling all services by default might have fatal consequences. E.g. a service that periodically fetches some data, then parses it (and subsequently gets exploited due to some bugs it might have).

AFAIU, the Debian policy of "enable services for all installed software" is in stark contrast with Fedora's default rule which says the opposite.

[marmarek]

Related: #2109 #1928 and #1625 (discussion at the end)

[Kixunil]

I've been playing with Debian packaging lately and I think I found a good way to resolve this. deb-systemd-invoke should be used by all packages. It's a wrapper that asks /usr/sbin/policy-rc.d (despide .d it's not a directory, but executable!) if it should execute a service.

I suggest creating a simple script at that location which will check the service against a whitelist of allowed services (Qubes daemons etc).

There's a second part to this though and that is enabling services. While my suggestion above would prevent services from running after install, they would still run after next boot. I don't know if there's a nice way to wrap deb-systemd-helper which is used for enabling. I suppose diversion would help. The wrapper should mask all newly installed services (except whitelisted ones) and unmask them during AppVM boot.

Still I'm unsure, if all services should be running in all AppVMs.

[marmarek]

Technically there is much better way to do that: systemd preset file which define what services should be automatically enabled - this is invented specifically to allow setting such defaults.

The question here is rather about policy: generally we don't change upstream policy decisions and Debian has more or less "if service is installed, it should be started automatically". Should we override it?

I think we had more detailed discussion about it somewhere, but can't find it now. @unman @adrelanos any opinions?

[unman]

I too seem to remember a discussion, but in my current somewhat addled state, cant remember where.

We do stop services on initial creation of templates, and I don't think that the proposed solution is of great help given that it takes a hit in the next boot. My gut feeling is that we should stick with Debian default, however painful that is.
If it's decided that we should stop this then we would have to create a wrapper round every install to stop on install and then block by default - not impossible by any means.

[adrelanos]

We can't or shouldn't harden Debian (much) since the result wouldn't be a Debian template with only necessarily modifications to integrate with Qubes. That would be a fork of Debian. Debian is a trademark.

https://www.debian.org/trademark

Forks of Debian shouldn't be called Debian to avoid confusion.

Instead, I would suggest to maintain a reasonably hardened by default Debian derivative. Any coming to mind? Perhaps Kicksecure?

https://www.kicksecure.com

Anyone up to maintain a Kicksecure Qubes template?

And then once such as template stabilized in Qubes consider installing only that by default and not "plain" Debian. That would avoid the discussion on whether (default less secure) distribution defaults should be honored. No change of upstream policy but Qubes becoming "upstream" by not calling it Debian but its own name that it deserves.

[Kixunil]

@marmarek fair, would it be fine to at least disable it in template VM? Possibly provide a very easy way to turn it on (or make it opt-out). Not running things like mpd in template VM would be nice.

[adrelanos]

Please don't create file /usr/sbin/policy-rc.d directly as this might cause issues:

• /usr/sbin/policy-rc.d file exists which prevents daemons from (re-)starting during package upgrades #8316

It's not needed. If needed in a script, could be used similar to:

• dpkg-noninteractive
• apt-get-noninteractive

[ -n "$POLICYRCD" ] || POLICYRCD="/usr/share/usability-misc/policy-rc.d"
export POLICYRCD

[adrelanos]

Potential other alternatives:

• https://packages.debian.org/bookworm/policy-rcd-declarative
• https://packages.debian.org/bookworm/policy-rcd-declarative-allow-all
• https://packages.debian.org/bookworm/policy-rcd-declarative-deny-all

[3hhh]

Good find!

So the original request is identical to sudo apt install policy-rcd-declarative-deny-all in the debian template.

It should be rather straightforward to pull in that poackage from some Qubes OS package. If there's any Qubes service that must run immediately after being installed, the default policy will have to be extended a bit.