Cannot open files in disposable VM using SecureDrop Client

[eloquence]

As observed in #751 (comment), I'm unable to open files in disposable VMs from the SecureDrop Client app on Qubes 4.1 after an in-place upgrade. This is not necessarily a blocker on #751 as it's not been reproduced on fresh install (the recommended procedure), or indeed by anyone else yet.

Steps to reproduce

1. Upgrade to 4.1 via in-place upgrade per https://www.qubes-os.org/doc/upgrade/4.1/
2. Provision SecureDrop Workstation
3. Run the SecureDrop Client, login and download some stuffs
4. Open a file from within the SecureDrop Client

Expected behavior

• Magic, rainbows, and a file opened in a disposable VM

Actual behavior

• Nothing happens

Findings

• Manually running the qvm-open command the Client constructs triggers an RPC policy violation
• Changing the deprecated $ to @ resolves that and files do open in disposable VMs
• Regardless, the Client never runs the command at all
• The Client attempts to execute the command via Qt's QProcess. Early testing suggests that this exits with return code 5, but I've not dug deeply into that yet.

[eloquence]

I tracked this down to an AppArmor denial:

May  2 21:10:07 localhost kernel: [   89.060174] audit: type=1400 audit(1651551007.556:14): apparmor="DENIED" operation="exec" profile="/usr/bin/securedrop-client" name="/usr/bin/expr" pid=991 comm="qvm-open-in-vm" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0

This in turn appears to be the result of a change in qvm-open-in-vm in Qubes 4.1, which now uses expr as part of its argument parsing. expr is not in our AppArmor profile for SecureDrop Client, which causes attempts to (indirectly, via qvm-open-in-vm) execute it to fail.

I don't know why I'm the only tester who has encountered this issue, however. Could others on Qubes 4.1 who can successfully open files in disposable VMs please check if:

1. Their AppArmor profile is enabled in sd-app (sudo aa-status should show a profile being enforced for /usr/bin/securedrop-client)
2. Whether their version of qvm-open-in-vm includes the commit above

Regardless, I'll open a draft PR with the AppArmor policy change in case we need it.

[eaon]

Oh interesting. there is no AppArmor denial on a fresh 4.1 install, and it looks our qvm-open-in-vm versions differ. Does upgrading to 4.1 also change templates' Qubes repositories? Because on a fresh install the template will just default to 4.0 repo packages…

[eloquence]

That may indeed have been a consequence of the in-place upgrade; I see that 4.1 repos are in my /etc/apt/sources.list.d/qubes-r4.list. My assumption is that this is the desired state, so we will need the fix in freedomofpress/securedrop-client#1485 to avoid DispVM breakage once all aspects of the migration are in place. Can you see if switching to 4.1 repos for sd-small-buster-template introduces AppArmor denials (when opening files from within SecureDrop Client)?

[eaon]

Confirmed, seeing the same AppArmor failure with 4.1 repos.

I ran into some issues with conflicting file locations between different Xen packages, but used dpkg -i --force-overwrite to install xen-utils-guest. I haven't looked at how the updater solves this conflict, but if we're interested in adding an in-place upgrade path we should probably replicate that rather than automating my manual intervention.

Checking out the draft PR now

[eloquence]

(Re-titled and labeled as blocker for 4.1)

[sssoleileraaa]

I also could not repro on a fresh install of 4.1 and can confirm that we're not interested in adding an in-place upgrade path.

[sssoleileraaa]

That may indeed have been a consequence of the in-place upgrade; I see that 4.1 repos are in my /etc/apt/sources.list.d/qubes-r4.list. My assumption is that this is the desired state

This is the desired state! So, it sounds like our fresh installs are not using the correct 4.1 repos, which should be opened in a separate issue, especially as we continue to review and test the 4.1 migration PRs.

Update: Oops, nvm, maybe this isn't the desired state until freedomofpress/qubes-template-securedrop-workstation#24 is released.

[sssoleileraaa]

@eaon wondering if you could add your thoughts on whether or not this is actually a blocker? At first I thought we weren't testing the right thing, but we are in fact testing what users will also experience: their fresh install will also point to the 4.0 repos until freedomofpress/qubes-template-securedrop-workstation#24 is done and rolled out. It looks like @eloquence's draft PR adequately fixes this issue, but I think we'll have to do a lot more testing as part of review/QA for freedomofpress/qubes-template-securedrop-workstation#24 rather than 4.1 support? What do you think?

[eaon]

Per discussion from this afternoon, we're planning to release 4.1 support with bullseye templates only (which we'll not support for 4.0) and they use the appropriate repositories by default. In that case, this would indeed be a blocker, but yes @eloquence already (very likely 🤞) figured out the fix for this particular problem in freedomofpress/securedrop-client#1485

Once bullseye templates are available we'll have to more in-depth testing of other components which might still need tweaking.

[sssoleileraaa]

@eaon - I believe this issue is resolved now that we merged #784. Is that your understanding as well?

[eaon]

I believe/hope so, but I don't think any of us have tested client functionality beyond "it starts!" yet. So I believe I'd opt for waiting a little bit longer

[rocodes]

(Closing since this was resolved and our 4.1 support is now complete + in-place)