"Default service policy" popup after prod uninstall via sys-whonix

[eloquence]

After a prod uninstall that completed with only the warnings noted in #505, I'm seeing this popup:

[conorsch]

Essentially the same problem as reported in #477, although the screenshot is great to have. I believe the proper resolution here, for both "uninstall" and "make clean" cases, would be to update the securedrop.Log RPC file in-place to deny submissions. That's essentially what the salt logic does to whitelist the disp-mgmt VMs in the VMShell RPC policies, temporarily for the duration of a given salt run.

[conorsch]

update the securedrop.Log RPC file in-place to deny submissions

By way of example, see here: https://github.com/QubesOS/qubes-mgmt-salt/blob/3a8b5b6b87519dbbd054d4df27e3f5e455a6b561/qubessalt/__init__.py#L287-L306 That'd allow us finegrained control of when it's permissible for sd-log to receive log events. Currently in our salt config we'd have to write that in twice, once for the dev logic, and once for the prod/staging logic. That's not worth the duplication, so I'll take a closer look at #505 since that'd help in both situations.

[conorsch]

Currently in our salt config we'd have to write that in twice, once for the dev logic, and once for the prod/staging logic. That's not worth the duplication, so I'll take a closer look at #505 since that'd help in both situations.

I'm wrong about that. In all environments, we call destroy --all, which is Python code, so we could indeed add the RPC policy adjustment in a single location to avoid the race where sd-log is prevented from shutdown & removal because it's still receiving log events.

[conorsch]

Still seeing this occasionally. The log event is coming from sys-whonix, which is still using the securedrop-log code, because our clean action removes the package and config from the TemplateVM, i.e. whonix-gw-15, but doesn't reboot sys-whonix. We never permit sys-whonix to log to sd-log, but after removal of the RPC policies, dom0 offers to create the now-missing service. To resolve, we can either:

1. reboot sys-whonix after uninstall
2. update the RPC policy for securedrop.Log to default deny all, and leave that file in place after uninstall

Option 1 is the cleaner approach, but we may wish to implement 2 during reboot.

[eloquence]

Related: #672 for suppressing this popup during normal use (but it's a separate issue, since such default denials would presumably be removed as part of an uninstall)

[legoktm]

backlog pruning:

This only happens in the case of the whonix VM because we modify that template but leave the VM running. So Option 3 would be to get rid of Whonix (which is already tracked). The default deny RPC policy in Qubes 4.2 won't help since this task is post-uninstall.