SecureDrop simplification

1

Bonjour,

What if … SecureDrop was exclusively using a tails derivative ? In this tails derivate there would be all packages SecureDrop needs. For OSSEC, app server, admin key, SVS, journalist key. The tails installer would show a choice for the type of installation (mon, app, svs, journalist, admin) and store site-specific in its persistent partition.

We start the installation with the admin key. When it starts a browser shows a fullscreen web page (flask based) with all values found in site-specific. We plug the USB key on the app server (which is has not been installed with anything yet) and we install tails on the disk (the installer is modified to accept non-removable media as a valid installation option). We select the “app” installation type and when it is complete the journalist-aths + source-ths + app-ssh-ths + local IP are persisted on the admin key.

We then move the admin key to the mon server and install from the “mon” installation type using the “app” server local IP stored on the admin key. Andthe mon-ssh-ths is persisted to the admin key. And we can use ssh mon and ssh app from the admin key.

And we finally install the SVS on a USB key this time. And the journalists key is created from the web interface on the admin key which can ssh to the app to create it and create the USB key with links to the journalist + source interface using ths/aths collected during the installation of the app and stored on the admin key.

Pros:

  • There is only one distribution (tails) instead of two (ubuntu/tails)
  • The sysadmin installing SecureDrop is required to
    • enter all parameters (i.e. ./securedrop-admin sdconfig)
    • plugin the admin key on each machine in sequence, click install + the role ofthe machine
  • The journalist keys are created from the admin key, including their credentials
  • All updates and installations are from debian packages + a configuration file with the initial values entered by the user, there is no ansible
  • The SVS could be packed with tools like pdf-redact-tool or a search engine and pretty much everything already packaged in Debian GNU/Linux that could be useful to work offline.
  • The app / mon reboot daily and are amnesic which is presumably better for security than a long lived system like Ubuntu

Cons:

I realize this is significant work. And also that it’s going in a direction that is orthogonal to where we’re currently spending most of our efforts. I’m not saying we should do that. Maybe there is something better. Maybe it’s not such a good idea overall. But maybe there is something to explore. I specially like that

  • the sysadmin experience is simplified to the minimum (i.e. entering parameters + booting on USB keys + choosing the type of install).
  • the journalist experience with the SVS improves because there are more tools

Given the how busy the FPF staff is (and is going to be in 2018) it is unrealistic to even think of such a radical change of direction. But if people in the community did something like this and provided a convenient upgrade path for existing SecureDrop users, it could lead to a much better experience (for the journalist because the SVS has many more features) and for the admin (because the admin key is a central point for server install & upgrades and journalist + SVS key creation & upgrades).

Food for thought :slight_smile:

2

Are you suggesting we replace Ubuntu on the servers with Tails? I mean… tails update strategy and amnesiac nature is pretty similar to the idea I brought up in the roadmap meeting (regarding using libostree), that received a lot of critical pushback from the team:

From Tails derivative page:

We offer automatic upgrades which are binary diffs from one ISO image to the other.

Honestly, I think whatever we do on the servers we need to control the whole stack … basically every other Linux appliance does this (including Tails) – I don’t see why it’s far-fetched or crazy for SecureDrop to also do this. I think it’s very telling that a large organization that is very experienced in maintaining distributions - RedHat, whom owns ansible, didn’t turn to ansible to manage appliance updates and instead started working on a product to push entire filesystem updates.

I realize this is significant work. And also that it’s going in a direction that is orthogonal to where we’re currently pending most of our efforts. I’m not saying we should do that. Maybe there is something better. Maybe it’s not such a good idea overall. But maybe there is something to explore. I specially like that

If we don’t spend the effort of trying to drastically re-engineer the current SecureDrop server model — we are just going to fall flat attempting to scale our services. We can’t keep running around to do in person on-sites every time there is a security vulnerability (and there will be more, thats just the nature of our product having a state-level adversary and us being humans that make mistakes sometimes). The product should be very easy to install and consistent with installing other operating systems (you load medium, go through guided menus, voila). At least that should be our goal we are constantly striving towards.

All that being said, I’m in the same boat here of trying to radically change the server architecture. I’m not 100% sold that making a Tails derivative is the best bet vs. say a CentOS derivative. However, I do like your argument that since we would already be heavily tweaking Tails we could keep going down that path to make the server environment a Tails derivative.

3

Yes. But your arguments stayed with me. I was strongly opposed to adding yet another distribution when we discussed. libostree + tails + ubuntu … seemed a bit much. Hence the idea of reducing this to just tails, if at all possible.

4

After thinking about this a little more, I realize this is probably an implementation detail. What really matters is to define a user experience that is really easy for installation, updates and disaster recovery. I’m under the impression that it’s what we’re after, with libostree or docker or tails.

In the initial message the most valuable suggestion probably is to have an installation workflow that is:

  • ask for sdconfig values
  • move the USB key around, in sequence, to configure each machine

A secondary problem is to figure out a way to implement this in a way that is compatible with our skills and available time. It would be meaningless to dream of something that we don’t have the means to implement :wink: