Implement support for OSSEC alerts via Signal behind a feature flag

[eloquence]

Feature request

Description

Due to the complexity of setting up GPG keypairs and the additional "push" benefit that a Signal messages provide, we would like to experiment with Signal as an alternative means of delivering security alerts from the Monitor Server.

User Stories

As a SecureDrop administrator, I would like to receive a Signal message when there is an OSSEC alert about my SecureDrop instance.

Related tasks

• Test current signal CLI branch - Test and review current signal CLI branch #3188
• Upgrade servers to Ubuntu Xenial to avoid reaching EOL on Java included with Trusty
• Decide on containerization strategy and implement, if appropriate

Additional background

This work is in progress at https://github.com/freedomofpress/securedrop/tree/experimental-signal-cli-0.6

[emkll]

Since Signal has become a very widely adopted, easy to use and secure messaging solution, we have decided to explore the feasibility of using Signal for SecureDrop OSSEC alerts instead of GPG-encrypted email. Some preliminary work is underway in this branch: https://github.com/freedomofpress/securedrop/compare/experimental-signal-cli-0.6

A couple points that might be worthy of discussion:

1. signal-cli: To the best of my knowledge, https://github.com/AsamK/signal-cli is the only library suited for this purpose. It relies on https://github.com/signalapp/libsignal-service-java for cryptographic operations and communication. It appears to be fairly well maintained and most of its functionality is around device management (contacts, devices, configuration, files), but has not been audited. It is, however, being used by Haven.

2. Using Java: SecureDrop has traditionally been a project with very little dependencies to reduce potential attack surface, introducing openJDK would be somewhat of a departure. Keeping in mind that this would only be installed on the monitoring server, and that the use of signal notifications (and therefore openJDK install) would be on a strict opt-in basis, would this be acceptable from both a security and support perspective?

3. Attack Surface: I would appreciate everyone else's perspective on this, but the incremental risk appears quite limited, given that, at runtime:

   • the only interfaces that could potentially introduce risk are:
     • logs/ossec alerts being sent to messaging app
     • a maliciously crafted message/attachment sent by an attacker (though messages/attachements are parsed/processed when the receive command is invoked, which is currently not used)
   • the app server is exposed to the mon server exclusively though ossec server talking to ossec agent.

4. Support: signal-cli has a hard dependency on Java, and currently Ubuntu Trusty repos have openJDK7, based on IcedTea distributed maintained by Redhat which will be EOL in June 2018. We could use Xenial repos to get openJDK8, but will likely cause some challenges with apt pinning. Should we perhaps prioritize upgrade to 16.04 which will provide further benefits?

5. Sandboxing: In the current working branch, an AppArmor profile is being used to sandbox Java. As @dachary suggested, it would definitely best to run signal-cli in a container, however there is a hard dependency on the entire containerization story. Given that it's entirely opt-in, would a feature flag as described in this ticket make sense as a stopgap until the containerization efforts are completed?

6. Build/packaging: The current deb packaging build logic uses the jar files signal-cli maintainer. One important next step is to build these from sources, likely using the sd-builder container. This is more maintenance burden that we would need to take on.

7. Licensing: We would need to make sure per the point above that our packaging and usage of all libraries is compliant, I would appreciate some feedback and next steps, if any, on this point, once sufficient progress has been made on the build/packaging step described above.

[redshiftzero]

Thanks for this excellent writeup @emkll. Based on 4 alone I think that this issue will need to wait until we're running Xenial. Regarding sandboxing, I'd prefer not implementing a stopgap and instead implement this with all the hardening we think is appropriate for installing Java (😬) on the monitor server.

[ageis]

I'm just going to leave this here for anyone interested. https://grafana.com/blog/2019/08/22/homelab-security-with-ossec-loki-prometheus-and-grafana-on-a-raspberry-pi/