Packaging strategy for signal-cli


To quickly summarize the various discussions regarding the availability of signal-cli as a mean to send alerts from the monitor (the ideas is not new), @mickael experimented the integration with SecureDrop and I explored options to package it.

Ideally it would be available in Debian GNU/Linux and Ubuntu but after a few weeks exploring this path, it cannot happen because the upstream is not amicable to the idea. We could package it on our own, of course, but that is a sizeable amount of work to chase upstream and even more difficult when it does not care to help when something as simple as tagging releases comes up.

@mickael experimented with the binary signal-cli package which contains about two dozen binary Java packages downloaded from maven. That allowed us to precisely identify which version of each library we need.

The only problem left to resolve is to be able to rebuild each java dependency from source so we have something reproducible instead of a set of binary blobs of unknown origins. I propose we build, upload to the docker hub and maintain a docker image. This docker image can then be installed on the monitor and used as if it was a command line, embedding all dependencies.

In terms of dependencies added to the monitor it would be:

  • the docker engine
  • the signal-cli image we build

What do you think ?

@mickael I’m curious to know more about your reservations regarding running the Docker daemon on the monitor?

Great summary, @dachary !

I think using a container to build is definitely a good idea to build other deb packages.

My reservations are mostly that we need need to settle on a single container runtime. I think that with proper configuration (grsec, seccomp and reduced capabilities) Docker can be fairly secure, but there are more lightweight libraries that can be used such as using runc directly which would expose less attack surface than the entire Docker container.

Regardless, the mon server is definitely a good place to start container migration. This sounds like something that should be discussed at the next engineering meeting :slight_smile:

expose less attack surface than the entire Docker container.

I’d like to better understand this. Say we have signal-cli running on the host, not in a container. It has a given attack surface. Now, say the same signal-cli is running inside a container and the container is running the same version of the OS as the host and does not run in --privileged mode so it has slightly less permissions that the host. In which way does the Docker container have a larger attack surface?

Sorry! I meant the Docker engine! The Docker engine runs as root configures the host and alters system configuration, iptables, can pull and run images from the internet. In other words, it would be a fairly complex and critical component.

Hum, I see. I understand that there should be a strong incentive to have the Docker engine as a dependency. And, for the reasons you described above, you would rather have SecureDrop use a deb package instead of a docker image to distribute signal-cli. I trust your judgment on these matters and that makes sense.

Out of curiosity (and not as a sneaky way to change your mind ;-), would you say the docker engine is properly maintained from a security point of view?