Package vm-specific files

emkll commented 5 years ago

We use Salt to move certain configuration files to VMs when invoking Make commands in dom0. These files include files used for mime associations and default behavior for opening, but also Python scripts (in the case of sd-export):

We should distribute these using .deb packages to ensure we are in a position to easily and automatically update them, without invoking any dom0 Make commands, nor requiring to update the securedrop-workstation source code.

eloquence commented 4 years ago

Is this issue fully superseded by packaging work that's part of template consolidation (#471)?

conorsch commented 3 years ago

To my eye, yes, it is. However, there are still a few scripts in dom0 that really should be bundled up in the RPM, to my eye, although perhaps that's best rephrased in a new issue.

zenmonkeykstop commented 1 year ago

Ongoing and planned work on provisioning improvements will catch the stragglers here. Leaving open for now.

rocodes commented 5 months ago

Posting some notes so we can decide next steps. To recap, packaging files rather than updating them via salt will make it easier to reason about system status, perform migrations, depend less on Salt, etc.

Most files managed by Salt are in dom0

# fully managed (created, deleted) using Salt - /etc/yum.repos.d/securedrop-workstation-dom0.repo - /etc/pki/rpm-gpg/RPM-GPG-KEY-securedrop-workstation - /etc/pki/rpm-gpg/RPM-GPG-KEY-securedrop-workstation-test - /usr/share/securedrop/icons - /home/{{ gui_user }}/.config/autostart/SDWLogin.desktop - /usr/bin/securedrop-login - /etc/qubes-rpc/policy/securedrop.Log - /etc/qubes-rpc/policy/securedrop.Proxy - /home/{{ gui_user }}/Desktop/securedrop-launcher.desktop - /home/{{ gui_user }}/.securedrop_launcher - /srv/salt/qa-switch.tar.gz - /srv/salt/qa-switch - /srv/salt/consolidation-qa-switch.sh - /etc/qubes/policy.d/60-securedrop-workstation.policy - /etc/qubes/policy.d/70-securedrop-workstation.policy # system files modified via salt - /etc/crontab - /etc/systemd/logind.conf - /etc/qubes/repo-templates/qubes-templates.repo - /etc/qubes-rpc (legacy) files, including specifically: - /etc/qubes-rpc/policy/qubes.ClipboardPaste - /etc/qubes-rpc/policy/qubes.PdfConvert - /etc/qubes-rpc/policy/qubes.USB - /etc/qubes-rpc/policy/qubes.USBAttach - /etc/qubes-rpc/policy/qubes.Gpg # permissions changes via salt - /opt/securedrop/launcher/sdw-launcher.py - /opt/securedrop/launcher/sdw-notify.py - /home/{{ gui_user }}/.config/autostart/SDWLogin.desktop - /usr/bin/securedrop-login - /home/{{ gui_user }}/Desktop/securedrop-launcher.desktop

There are still some VM specific files that are managed or modified via Salt

# all vms: - /home/user/.local/share/applications/mimeapps.list (default handling or custom handling. symlink to correct mimeapp file done via Salt during provisioning) - /home/user/.mailcap # symlinked to /opt/sdw/mailcap.default in salt, file is installed by workstation config .deb package - /etc/sd-rsyslog.conf # copied in via salt - FPF apt repolist file (/etc/apt/sources.list.d/seuredrop_workstation.list) # some vms - /rw/config/rc.local # various purposes. eg in `sd-gpg` and `sd-log` it disables logging, in `sys-usb` it loads udev rules - /home/user/.profile # in `sd-gpg` it sets split GPG vm env var # specific cases - sd-gpg: /home/user/.profile # QUBES_GPG_AUTOACCEPT, /home/user/.gnupg # permissions change - sd-gpg: /home/user/.gnupg/sd-journalist.sec # note, updateable content, not static packageable file - sd-app: /home/user/.securedrop_client/config.json # note, updateable content not static packageable file - sys-usb: /rw/config/sd/etc/udev/rules.d/99-sd-devices.rules, /etc/udev/rules.d/99-sd-devices.rules - sd-proxy: /home/user/.securedrop_proxy/sd-proxy.yaml (to be replaced by qubesdb config for proxyv2?; Permissions adjusted in Salt) - sd-whonix: /var/lib/tor/keys/app-journalist.auth_private # note, updateable content, not static file - sys-firewall: /rw/config/RPM-GPG-KEY-securedrop-workstation{-test), other pubkey/update related files, but that may change with updater changes

And many files are already managed by packages in both dom0 and in VMs (the workstation-config debian package for VMs, the workstation-dom0-config rpm for dom0).

Looking at this, I think there are a few quick wins and a few discussion points.

Quick wins:

The mimeapps symlinking can be in a postinst script rather than during a Salt run (and there may be other similar small improvements like this that we can make in the workstation-config package)
Similarly, the dom0 config rpm can manage more of its own files
- (Unrelated but the rpm build process in dom0 itself can also probably be simplified since we don't "build" anything, i.e any binaries, we just install files)

Discussion

For modifying dom0 system files, we may take a more nuanced approach, eg: a) as much as possible phasing out the blockreplace in existing qubes system files to preference managing our own files instead (true for: template / repo configuration, RPC policies), but b) if we must modify system files, maybe have those changes bundled up into the config package instead of done via salt
- Or into 2 subpackages (dom0- what we install, and dom0- what system stuff we modify), which is easy to do with RPM spec files and might make for cleaner logical segmenting
Should we ship a package for sys-usb with the udev rules?
What did we decide re: bootstrapping- can we avoid Salt in the debian bootstrapping/fpf apt repo install phase when we stop shipping a custom template?

zenmonkeykstop commented 5 months ago

I think for that last point there would be some unavoidable Salt additions. At the very least we need to install our release pubkey and set up the repo. It looks like the steps would be:

verify existence of system template (debian-12-xfce for now) and install if not present
clone system template to make (say) sd-debian-12-base
apply same setup/config as currently goes into the built sd template to sd-debian-12-base
clone large and small templates from sd-debian-12-base

So the setup/config for the template is still Salt. We could just do the key and repo and move the rest into a debian -config package, maybe.

legoktm commented 3 months ago

I think https://github.com/freedomofpress/securedrop-workstation/pull/1043 addresses the last bit of this?

rocodes commented 3 months ago

Yeah - I came here to say we should close this and/or remove it from the board :) Any followup tasks will have their own specific tickets.

freedomofpress / securedrop-workstation

Package vm-specific files #274