search

freedomofpress / securedrop-workstation

Qubes-based SecureDrop Journalist Workstation environment for submission handling
GNU Affero General Public License v3.0
132 stars 39 forks source link

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

Open rocodes opened 2 months ago

rocodes commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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.