Use dh_apparmor for installing profile

[legoktm]

Status

Ready for review

Description

dh_apparmor generates the appropriate postinst and postrm snippets for (re)loading apparmor profiles in a way that seems more robust than our current usage of aa-enforce.

If apparmor isn't enabled, then it gracefully skips instead of aborting the installation. This allows for installing the client package in contexts where apparmor isn't available, like containers. Notably we can now enable piuparts testing for the client.

Fixes #1853.

Test Plan

• Build package, install in a qubes VM. Start client (just the login screen is fine), run sudo aa-status, see output like:

17 profiles are in enforce mode.
   ...
   /usr/bin/securedrop-client <-- this
...
4 processes are in enforce mode.
   /usr/bin/dash (10941) /usr/bin/securedrop-client <-- and
   /usr/bin/python3.9 (10944) /usr/bin/securedrop-client <-- this

• Spin up a podman/docker container, install the package and it succeeds. Run sudo aa-status to verify apparmor is not enabled.

[legoktm]

The one major change that happens here is that there is no longer a hard failure is apparmor is disabled. I think that check was dubious because it only happened during install time in the template and not in the actual running VM. So maybe we do want some check that apparmor is enabled in the sd-app VM? I would rather do that as part of freedomofpress/securedrop-workstation#939.

I was wondering if the securedrop-client script could tell if it was unconfined, we could

1. add enough things to the profile to allow running aa-status, and check the output
2. run a banned command, i.e. sudo true, or try a banned file access; if it fails then we know we're confined. this will generate constant denials in the logs though
3. have /usr/bin/securedrop-client be unconfined, check aa-status to ensure profile is loaded, then invoke /usr/bin/securedrop-client.real, which is confined.

No. 2 actually tests that we're confined, whereas 1 and 3 are just relying on aa-status to be true.

[legoktm]

or try a banned file access; if it fails then we know we're confined

For example, adding this to /usr/bin/securedrop-client:

if ls /usr/bin/sudo 2>&1 >/dev/null; then
    echo "Unconfined"
    exit 1
fi

And then running sudo aa-complain /usr/bin/securedrop-client causes the client to not start.

[cfm]

This looks good, @legoktm, and I like the approach you've sketched here.