4.1 support: sys-usb DispVM compatibility and sd-log qrexec loopback denial notification suppression

[eaon]

Description of Changes

Fake "stacked" PR waiting for #751 being merged first. Towards #600.

The Qubes OS 4.1 default configuration makes the sys-usb qube
disposable, which interferes with our udev rule to automatically attach
flash devices to sd-devices. This change clones the fedora-34-dvm
qube as sd-fedora-dvm, where we henceforth add the necessary
modifications, so sys-usb stays disposable, but with our modifications
sticking around permanently.

In 4.1 policy denials trigger a notification visible to the user -
qexec loopback isn't supported in 4.0 either, but they're silent.
Suppressing these notifications is only supported in the new policy
format, so securedrop.Log rules are now there.

Fixes #755

Testing

• QubesOS version:
• If 4.1, sys-usb is a DispVM:
• Workstation environment:
• Server environment:

dom0

• During the initial sdw-admin --apply run, there are no error notifications along the lines of sd-log tries to log to itself, but loopback qrexec connections aren't supported #755
• sdw-admin --apply successfully terminates
• All tests (make test) pass (prerequisite: Release securedrop-workstation-config 0.1.7 securedrop-builder#312 is fixed)

Updater (4.1 only)

• During the update, no error notifications along the lines of sd-log tries to log to itself, but loopback qrexec connections aren't supported #755 are shown

Client

• When a USB flash drive is connected to the machine, it is automatically attached to sd-devices (which boots if it is not running)
• Export UX works as expected (see [export instructions in Workstation Acceptance Tests(https://github.com/freedomofpress/securedrop-workstation/wiki/Workstation-Acceptance-Tests#export)])

Deployment

For new 4.1 installs both sys-usb DispVMs (default configuration) and AppVMs are supported, though I think we should advertise the default configuration in the docs.

If migrated 4.0 installs keep modifications to their sys-usb AppVM during/after upgrade, the salt states should also continue to work as expected on 4.1.

Checklist

If you have made changes to the provisioning logic

• All tests (make test) pass in dom0

[eloquence]

Question: Could it make sense to instruct users to set up sys-usb as persistent, and therefore avoid having to customize it in this manner?

[eaon]

Could it make sense to instruct users to set up sys-usb as persistent …

I'd tend towards supporting default configurations in any case - that choice is made on one screen and changing any sys- qube from DispVM to AppVM (or vice versa) is involved enough to not ask users to do that, and requiring a reinstall just for that would be a shame too (from a time-sink perspective).

As far as I can tell, there's no real downside to this way of handling it, we get updates from the base template, we have our "permanent" customisations but get the benefits of sys-usb being a little bit more protected.

[eloquence]

(As discussed, I'll take this for a quick spin on my in-place-upgraded setup which uses 4.1 repos in the SecureDrop Workstation templates.)

[eloquence]

• QubesOS version: 4.1 (in-place upgrade)
• If 4.1, sys-usb is a DispVM: no
• Workstation environment: staging, built from this branch, SecureDrop Client 0.7.0rc3 (latest on apt-test)
• Server environment: production (2.3.2)

General note: Because exports also rely on qvm-open-in-vm, they will fail on a fully 4.1 system until freedomofpress/securedrop-client#1485 is merged. I manually applied this AppArmor change before testing.

On this system, both exports and logging don't work; I've not double-checked, but I doubt it's related to the changes on this branch. sdw-admin --apply with an RPM from this branch runs without errors and makes no changes to sys-usb since it's not disposable. All export attempts fail with ": See your administrator for help". I don't see any RPC policy errors in dom0, or AppArmor denials in sd-app or sd-devices.

USB devices are auto-attached and show up in Nautilus, and I'm able to mount them manually in sd-devices. Logs from sd-devices indicate that the preflight check returns a USB_CONNECTED result but does not continue from there. In debug mode, SecureDrop Client just logs a preflight check failure without further information. Will need to dig further into the code to see where it's not getting the result it expects.

As for logging, I'm continuing to observe the issue I reported here: #751 (comment) - I've split this out into its own issue (#773).

[sssoleileraaa]

@eaon - does this sound like the right order of next steps:

1. Test and merge Fix AppArmor rules for Qubes 4.1; update dispVM syntax securedrop-client#1485 against a 4.0 system to fix the issue @eloquence mentioned above (:heavy_check_mark: DONE but currently can't merge due to a github issue)
2. Test and merge this PR once a reviewer tests on a 4.1 fresh install (it's fine if the system still points to Qubes 4.0 repos for now - we'll test against Qubes 4.1 repos later)
3. Merge Initial support for Debian Bullseye templates qubes-template-securedrop-workstation#24 and rebuild all 9 workstation packages for Bullseye
4. Do a full round of QA on a fresh 4.1 install with the new template and kernel

There are some details we'll need to discuss around steps 3 and 4, which we can flesh out in the next sprint or two.

[sssoleileraaa]

On this system, both exports and logging don't work; I've not double-checked, but I doubt it's related to the changes on this branch. sdw-admin --apply with an RPM from this branch runs without errors and makes no changes to sys-usb since it's not disposable. All export attempts fail with ": See your administrator for help". I don't see any RPC policy errors in dom0, or AppArmor denials in sd-app or sd-devices.

USB devices are auto-attached and show up in Nautilus, and I'm able to mount them manually in sd-devices. Logs from sd-devices indicate that the preflight check returns a USB_CONNECTED result but does not continue from there. In debug mode, SecureDrop Client just logs a preflight check failure without further information. Will need to dig further into the code to see where it's not getting the result it expects.

I think you're right that this seems to be unrelated to this PR after reviewing the code changes here. But we'll have another opportunity to do a full round of testing against a prod-like environment in step 4.

[eaon]

@creviera That order of operation looks totally right to me yes!

[eloquence]

I dug a bit further into why exports aren't working on my 4.1 system. export.py runs this qvm-open-in-vm command:

https://github.com/freedomofpress/securedrop-client/blob/main/securedrop_client/export.py#L115-L118

The command appears to return no output, when the script expects output such as USB_CONNECTED to determine the preflight status (the preflight bundle is opened correctly on sd-devices). I'll do a bit more digging into 4.0/4.1 differences to see if this is another qvm-open-in-vm behavior change. @eaon I'd be very curious if exports work for you with 4.1 packages in all templates.

[eloquence]

Dug a bit further into the export issue and indeed it's again a difference between the 4.0/4.1 version of qvm-open-in-vm, see #775. So this is definitely an issue we have to resolve for full 4.1 support, but not related to this PR.

[cfm]

Assigning to myself to test as soon as I have Qubes 4.1 installed (which I'll prioritize next week).

[sssoleileraaa]

• Export UX works as expected (see [export instructions in Workstation Acceptance Tests(https://github.com/freedomofpress/securedrop-workstation/wiki/Workstation-Acceptance-Tests#export)])

Could someone confirm that we won't be able to see this PR's test plan pass until #775 is fixed?

[sssoleileraaa]

Based on my reading, this explains why export failed on my 4.1 fresh install. So I'm assuming this PR is blocked until #775 is fixed, probably using the solution @eloquence and marek hashed out in the issue (using qrexec-client-vm directly instead of qvm-open-in-vm within the client). I can volunteer to make this change in the client on Monday or Tuesday next week, but don't want to step on anyones toes (so @eaon or @eloquence, we should sync up on Monday :)).

Also, do we want to remove this test from this PR's test plan and not block on this issue? Or shall we consider it blocked? Looking for your feedback @eaon.

[eloquence]

FWIW, it doesn't look to me that any reviewer has successfully stepped through the full test plan on 4.1 yet, so it might be best to wait until the the #775 fix lands to ease testing this PR. It should be a pretty small fix.

[sssoleileraaa]

Okay, this should be unblocked now. Not sure when I'll be able to test next week, but probably on Tuesday, unless @cfm gets to it first with his recent fresh install of 4.1.

[cfm]

I have Qubes 4.1 successfully installed and will test this tomorrow.

[cfm]

(Review postponed at @creviera's request; removing my assignment and deferring to her for the current status update. :-)

[sssoleileraaa]

LGTM based on visual review and @eloquence's confirmation that there is no effect when sys-usb is not disposable (we're not making main unreleasable by merging this).

Once this PR and freedomofpress/securedrop-builder#339 are merged, we'll be able to test packages in nightlies on apt-test. Yay! :)