Refactor mime-handling configuration from Salt (at provisioning) to systemd (at boot)

[deeplow]

• I have searched for duplicates or related issues

Description

Partly fixes #1004, by moving mime-time overrides onto systemd services for provisioning at boot.

How will this impact SecureDrop/SecureDrop Workstation users?

How will this impact SecureDrop/SecureDrop Workstation users?

No user implications.

How would this affect the SecureDrop Workstation threat model?

Along with #1001, this assumes we are comfortable with runtime (boot-time) configuration of VMs' roles and services, #936 (comment).

[deeplow]

Quoting @rocodes from another thread:

Wasn't there mime handling config added in sd-proxy specifically to avoid it opening files?

Yes: https://github.com/freedomofpress/securedrop-workstation/blob/d72c73ceb90db81bc8c93ee6c8312e4e9a3f9122/sd-proxy/mimeapps.list

sidebar: istr Marek mentioning a better way to deny this kind of functionality rather than trying to compete with all the places that mime handling could be introduced, and rather than having to specify every filetype, which has been a source of errors for us in the past. qubes-core-agent-linux does contain some mimetype overriding: it looks like they ship both mime-override and xdg-override (look in /usr/share/qubes/ for respective directories) so it would be cool if we could do something similar.

But in any case for the purposes of this PR, I think we could either use the systemd approach that we're planning for other VMs, or just create the symbolic link to the "default" mime handling (which I think is just used for the proxy?) in the deb postinst and then override it in the other vms.

[deeplow]

@rocodes said:

sidebar: istr Marek mentioning a better way to deny this kind of functionality rather than trying to compete with all the places that mime handling could be introduced, and rather than having to specify every filetype, which has been a source of errors for us in the past. qubes-core-agent-linux does contain some mimetype overriding: it looks like they ship both mime-override and xdg-override (look in /usr/share/qubes/ for respective directories) so it would be cool if we could do something similar.

I did look into before implementing the mimetype overriding via systemd (as opposed to salt). I decided not to do that approach while doing that PR because it would require more investigation on the actual effectiveness and some red flags popped up (and this is pretty critical code).

So my suggestion would be discuss that as a separate issue. Here are my findings:

• that was implemented as app-dispvm.*
• The non-dev docs say that this feature is experimental and may not always work (that could be outdated, though).
• There is a goal misalignment. Our goal is have strict mime handling while Qubes' is allow the users file that would open in certain applications open instead in disposables (the backend for this future GUI feature)
• Qubes' approach relies on applications honoring XDG env variables, which I don't think is a good assumption.

I think there are better approaches than the current we have. I think the answer is somewhere along the lines of what Qubes does, but:

1. actually overwriting directories and not just relying on env vars
2. restricting the only available .desktop files to the ones we want

But that said, my assessment is that considering this change when tackling the present issue (system provisioning) is a bit of scope-creep for now and we should address it separately.

[rocodes]

Yup I agree with you @deeplow, I'm musing about the future (and/or the proxy) but don't think this should be part of the immediate game plan, the changes you've proposed are solid