Refactor logging configuration from Salt (at provisioning) to systemd (at boot)

[deeplow]

Description

Implementing #1004 (salt -> systemd / qubes-services) for the particular case of logging.

Same as the parent issue:

How will this impact SecureDrop/SecureDrop Workstation users?

No user implications.

How would this affect the SecureDrop Workstation threat model?

Along with #1001, this assumes we are comfortable with runtime (boot-time) configuration of VMs' roles and services, except for secrets.

[deeplow]

Created this issue to have a canonical place to discuss implementation issues for two interdependent PRs (workstation#840) and client#1677).

Negative approach: securedrop-disable-logging

(current approach on main) A service enabled on qubes where logging is disabled. This was the original approach and follows what was previously implemented in salt.

[Unit]
Description=SecureDrop: Disable remote logging for sd-log and sd-gpg
Before=rsyslog.service
[...]
[Service]
Type=oneshot
ExecStart=/usr/bin/rm /etc/rsyslog.d/sdlog.conf

While this is entirely possible to keep, now that we're implementing this as Qubes features, it sounds a bit counter-intuitive to have a securedrop-logging-disabled feature.

Advantages:

• already implemented and works

Disadvantages:

• feels weird to have a service that disables stuff
• removing files on boot could lead to race condition bugs
• qubes which don't have securedrop-log package (e.g. sd-whonix) won't have logging enabled even though they don't have the securedrop-logging-disabled service.

Positive approach: securedrop-logging-client

This would be a qubes feature enabled on all the clients where logging is conducted. On start it would copy over sd-rsyslog.conf and sdlog.conf over to the appropriate locations in /etc/and/etc/rsyslog.d/`, respectively.

Advantages:

• feels more natural when implemented via qubes services (service enabled == the thing running)
• no mistakes of forgetting to enable logging

Implementation challenges:

• giving a bit of a headache to implement because the template also has logging, which means that it populates /etc/rsyslog.d/sdlog.conf on boot. This is fine, but the issue is that all it's decedents now also have that, which NOT intended.

[legoktm]

I agree with you that the positive approach seems more logical, but based on the implementation notes, it seems implementing the negative approach is easier (and also already done), so I'd favor that for now?

removing files on boot could lead to race condition bugs

What are you worried about, given that systemd would prevent rsyslog from starting until after our service finishes?

[deeplow]

removing files on boot could lead to race condition bugs

What are you worried about, given that systemd would prevent rsyslog from starting until after our service finishes?

Fair point! I'll implement it the negative way, then.