Enforce `sd-svs-disp` updates on login

[eloquence]

We'd like to use Qubes' native facilities for templates updates to the greatest extent possible. This is freedomofpress/securedrop-updater#34. The native updater is an opt-in updater: it requires the user to actively launch the updater app.

Opt-in is not sufficient for the most security-sensitive template, sd-svs-disp, which is used for the creation of disposable VMs that contain viewer applications. In this case, we want to enforce updates.

This is a feature proposal to add an updater that launches on login in a manner that clearly indicates to the user that sd-svs-disp updates must be run before using the client.

Proposed Acceptance Criteria

Given that the Securedrop Workstation has just been booted When I log into Qubes with my username/password Then I should see a dialog that informs me that security updates must be applied before using SecureDrop And it should give me the option to start the update And no updates should start until I choose this option And it should not be trivially possible to dismiss this dialog

Given that the "update required" dialog is open When I start the update Then security updates should be applied to sd-svs-disp template And it should be obvious when this process is ongoing And it should be obvious when this process is completed.

User Stories

• As a journalist user, I want to be informed clearly and succinctly about any steps I need to take before using the SecureDrop Workstation, so that I can focus on my work to the greatest extent possible.

• As a journalist user, I want my system to be up-to-date with security updates, so my sources and I are secure.

[eloquence]

For discussion purposes only, here are some example messages that could be shown to the user.

Screen 1

Security Update Required

Before you use SecureDrop on this computer, we need to apply available security updates to the system component used to open submitted documents. This typically takes less than 5 minutes, but can take longer if many updates are available.

[ Start Update ]

Screen 2

Security Update In Progress

You will see system notifications while the update is underway. Please do not shut down the computer while the update is in progress.

(busy indicator)

Screen 3

Security Update Completed

Updates to critical system components have been applied. It is now safe to use SecureDrop on this computer.

[ OK ]

Screen 4 (error case)

Security Update Failed

There was a problem applying security updates. Please do not use SecureDrop on this computer for now, and contact your administrator for assistance.

[ OK ]

[conorsch]

Took a stab at adding a desktop file to ~/.config/autostart/. The good news: it works! The mgmt VM starts and package updates are applied if found. The bad news: it displays a rather frightening error message shortly before firing:

Will do some more reading on the proper methods to run scripts at login in XFCE, both vanilla and under Qubes.

[eloquence]

@redshiftzero and I just discussed this a bit more. She made the point that even for the less critical templates, we want to eventually enforce updates (e.g., after a week or so if the admin hasn't run them manually yet).

Eventual enforcement seems tricky, and it sounds like the recent improvements in freedomofpress/securedrop-workstation#356 have reduced the update runtime to the 6 minutes vicinity for typical runs. <10 minutes feels like an acceptable typical on-boot update runtime during the beta to me.

As an iteration on the current state, how do folks feel about the following: 1) Iteration 1 for beta: Update all workstation-related templates on login, and remove the cron job. (For the beta, we'll inform users that if they use other non-SD templates, they should update them using the Qubes updater.) 2) Iteration 2 for beta: Add dialogs similar to the ones above, so the user has a bit more agency in the process and understands whether the update is still running or not (i.e. whether it is safe to shut down the machine / start using it). 3) Post-beta: Make further improvements to improve performance and user experience.

If that plan sounds reasonable, what I'd like to discuss next is how/whether the native Qubes updater GUI fits into (2).

[redshiftzero]

Something I just thought about: if the only time the user is doing updates is on boot, what happens if they never shut down the workstation? I think we'll still want to have a daily cronjob (of course with better user messaging).

[kushaldas]

Something I just thought about: if the only time the user is doing updates is on boot, what happens if they never shut down the workstation?

I do this all the time except travel or kernel updates.

[eloquence]

I think we'll still want to have a daily cronjob (of course with better user messaging).

How about something like this:

• We save the last timestamp of a successful update
• We have a daily cronjob that runs the exact same GUI flow if and only if it hasn't run in 24 hours

[redshiftzero]

yea that sounds reasonable, screen 1 text will just need to be customized for the on-boot launch and mid-use case

[redshiftzero]

after the most recent discussions, @emkll and I worked on a design doc, this is to solidify what the functionality should be based on the security requirements: https://docs.google.com/document/d/1py8nM0eIMynsnDVa73c_Ev2UWxc3-qqetlQK-jLG04Y/edit#

we want to ensure that we consider the cases where:

• user almost never restarts their workstation (i.e. we need to ensure that updates are not done at boot time only)
• user has network disconnected at login time (related to freedomofpress/securedrop-workstation#355, we want to ensure that updates will still occur when the network is reconnected)
• user continues to defer updates indefinitely

please take a look, comments and thoughts welcome!

[eloquence]

Thank you both for putting this together. :) I left a couple of comments in the doc. My biggest concern is with the >5 day scenario (see comment at the end) and with the complexity of the low capability mode, at least for beta.