Improve hardening of SecureDrop applications via Linux-native capabilities

[eloquence]

Identified as a medium severity finding in the December 2020 Workstation audit report (TOB-SDW-026), the auditors recommend hardening the applications to leverage Linux native isolation and sandboxing capabilities:

• namesapces
• control groups
• Linux capabilities
• No new privileges flags
• Seccomp filtering for syscalls

In the near term, we should enable to No new privileges flag to the applications we develop for the workstation: securedrop-client, securedrop-log and securedrop-export.

We can test for the presence these capabilities by inspecting /proc/<pid>/status and observing flag status, eg: No New Privs: 1, and then open a follow-up to track broader, more complete sandboxing, through the use of something like LXC, gVisor or other sandboxing frameworks.

[Original issue description by @emkll]

[rocodes]

backlog pruning:

• we can use this ticket to decide at a high level on the specific tooling we want to enable (apparmor for each command, etc)
• can look at different commands and make sure they have the most restrictive aa version (debian ships with a less restrictive profile, for example, for ease of use, but we can make sure to use known stricter profiles, and/or submit upstream profile work)
• we should make specific tickets for each component and/or move this ticket to the client repo