Install LibreOffice in sd-svs-disp template

[emkll]

Due to complexity around Java install and PaX flags: Java runs java as part of the install process, and paxctld does not run and apply to flag before that happens.

We will likely need to install Java twice:

• Install, PaX mprotect will block the java post install script
• Add m to java binary
• Reinstall, now Java (and thus LibreOffice) should work.

[conorsch]

There's WIP in https://github.com/freedomofpress/securedrop-workstation/compare/svs_disp_libre. A few observations so far:

1. The paxctld flags for sd-svs-disp are managed in https://github.com/freedomofpress/securedrop-debian-packaging/blob/ca926d5ee8a38713598991145f331def7b478bab/securedrop-workstation-svs-disp/paxctld.conf.svsdisp ; any updates outside the package logic, including Salt, will be clobbered on package upgrades.
2. We may not need to disable memprotect on the libreoffice binary at all; this issue reports memprotect failures on the java binary, so first confirm that the java paths are properly exempted.
3. The two-pass approach via bash script doesn't provide strong error handling; using retry logic in Salt may give us greater control over the resolution of apt state.

Based on the initial report, it seems that the java binary doesn't get the proper pax flag from paxctld before being invoked. That could be due to lack of proper path in the paxctld config, or it could simply be a race condition, where paxctld doesn't enforce quickly enough (triggered via inotify). A reasonable solution here is to check that paxctld is running via salt, and set the paxctld service check as a requirement of the libreoffice install.

[kushaldas]

There's WIP in https://github.com/freedomofpress/securedrop-workstation/compare/svs_disp_libre. A few observations so far:

1. The paxctld flags for sd-svs-disp are managed in https://github.com/freedomofpress/securedrop-debian-packaging/blob/ca926d5ee8a38713598991145f331def7b478bab/securedrop-workstation-svs-disp/paxctld.conf.svsdisp ; any updates outside the package logic, including Salt, will be clobbered on package upgrades.

I was looking at the wrong place :( I will update the right place then.

2. We may not need to disable memprotect on the libreoffice binary at all; this issue reports memprotect failures on the java binary, so first confirm that the java paths are properly exempted.

I disabled memprotect on libreoffice otherwise there are those grsec error messages in kern.log file. I thought of not having those will help in future.

3. The two-pass approach via bash script doesn't provide strong error handling; using [retry logic in Salt](https://docs.saltstack.com/en/latest/ref/states/requisites.html#retrying-states) may give us greater control over the resolution of apt state.

I will use this then. 🌈

Based on the initial report, it seems that the java binary doesn't get the proper pax flag from paxctld before being invoked. That could be due to lack of proper path in the paxctld config, or it could simply be a race condition, where paxctld doesn't enforce quickly enough (triggered via inotify). A reasonable solution here is to check that paxctld is running via salt, and set the paxctld service check as a requirement of the libreoffice install.

This is due to race condition where paxctld does not enforce on time for the java deb package installation.