Make sure SDW won't run if dom0 config rpm is uninstalled?

[rocodes]

• [x] I have searched for duplicates or related issues
• Related: #939, #https://github.com/freedomofpress/securedrop-workstation/issues/951

Description

Partly filing this for discussion purposes:

If the workstation-dom0-config package is uninstalled, sdw should not continue to work. This is especially true if we move towards packaging more files (eg RPC policy files, icons, etc) in the rpm %post, since those security-relevant files would be uninstalled if the rpm were removed, as would the updater.

Right now, when the dom0 rpm is uninstalled, the "happy path" towards running SDW (double-click on .desktop icon) ceases to work (good!) - the icon disappears and the updater logic is removed, so clicking on the desktop icon does nothing. But it's still possible for a determined user to run securedrop-client - and if we move rpc policy files to the dom0 config rpm, they'd be running the client without any of our inter-vm hardening.

This goes pretty far into "protecting users from themselves" territory, which is not particularly something I like -- if someone opens a dom0 terminal and sudo dnf remove securedrop-workstation-dom0-configs their machine, is that really something we should be trying to mitigate? -- but just filing since the proposal to put stuff in files and packages (as opposed to in salt and managed via sdw-admin --uninstall) would make this issue worse.

I think we could reasonably just close this. Or do a low-stakes idea such as printing a console warning on uninstall of the package advising users not to use sdw without the package. Or writing a service that does basic sanity checking about the machine, per the linked issues above.

How will this impact SecureDrop/SecureDrop Workstation users?

Depends on the path we choose. The harshest path (not endorsing just illustrative) would be to run something like sdw-admin --uninstall from the dom0 rpm %preun, which would run before the rpm is uninstalled, but I think that would be negative for developers and potentially for users. Less-harsh ideas are above.

How would this affect the SecureDrop Workstation threat model?

Ensure systems are not being used despite any components missing

User Stories

As a SDW user, I want to avoid accidentally using a misconfigured system As a SDW user, I do not want destructive actions (eg delete VMs) to happen without my consent As an SDW developer, I want to ensure that systems are running in a known state and receiving regular system updates.

[cfm]

I like the (partial, one-way) atomicity of triggering "sdw-admin --uninstall" from securedrop-workstation-dom0-config's "preun" scriptlet, but it looks like "preun" is also run during upgrade.1

My intuition is that this is rather one of the things we'd like monitored by #951 or pre-flight-checked by #939.

[legoktm]

I think there's a circular problem, because e.g. even if we had auditing like #951/#939, presumably those would also be (un)installed into dom0 by the RPM. And there's no (foolproof) way e.g. the sd-app VM can check into dom0 to see if the RPM is still installed.

In general I would support doing something like having the rpm fail uninstall if sdw-admin --uninstall was not run first (maybe also having it automatically happen on uninstall, but I'm a bit skeptical about that), but I wouldn't rank it too high in priorities of preventing users from doing silly things.

My current inclination is that this is one of the reasons uninstall is unsupported, so if a user somehow manages to do that, they're out of our hands. And if it's not too invasive/costly in dev time, restricting uninstall would be reasonable.

[rocodes]

Thanks both for your comments. There is a bit of a circular problem, that I think might only be resolved if we had an orchestration rpm that was basically a metapackage, that depended on all the other components (secrets, keyring, dom0 config files), which probably would be their own separate packages too.

I don't know that there's anything actionable to do right now, except that I wanted to discuss this since more things will be managed by the dom0 config rpm (vs the salt orchestration) and there are some knock-on effects of that.