search

freedomofpress / securedrop

GitHub repository for the SecureDrop whistleblower platform. Do not submit tips here!
https://securedrop.org/
Other
3.62k stars 688 forks source link

Add endpoint to source interface to query package version metadata #972

Open garrettr opened 9 years ago

garrettr commented 9 years ago

Now that we are providing automatic package upgrades, it would be helpful for us to be able to verify that an upgrade successfully landed on every known SecureDrop instance. We can sort of do this for securedrop-app-code because the version is displayed in the footer of each page on the Source Interface, but we cannot query the version status of the other packages we provide.

Since these packages are maintained and upgraded publicly, our package repo is public, and the servers auto-upgrade within 24 hours, there is not much security risk in leaking the versions of these packages (it's not something an attacker wouldn't just be able to easily infer). However, being unaware that package upgrades are failing and not being able to respond quickly to rectify such a situation is a serious security concern. Providing an endpoint that lists the versions of installed packages would help us monitor these systems.

I am not sure whether we should list the installed versions of all packages, all relevant packages, or only the packages that we provide. The 3rd option seems the safest to start with and also the most immediately useful. It is also generally useful to know what versions of Tor and Apache (at a minimum) the servers are running, especially when novel attacks on Tor Hidden Services are published (womp womp). However, publishing those might give an attacker more of an advantage and we should discuss the tradeoff.

This is related to the idea that FPF should receive some subset of sanitized OSSEC alerts. For example, we could also learn if an upgrade had failed by setting up cron-apt alerts to also email FPF. These email alerts would be encrypted, and could also include the relevant logs, which would be helpful for debugging. However, I do not think these efforts are mutually exclusive, and both may be developed in tandem, evaluated, and the best solution refined over time.

psivesely commented 7 years ago

@heartsucker Just a note that if something does not completely resolve an issue try to avoid use of "keywords for closing issues".

In https://github.com/freedomofpress/securedrop/pull/1528, @heartsucker created a new view for the app /metadata that lists the SVS key fingerprint and SD app code version as JSON. It should now be trivial to add additional information to this view, but we should further discuss the trade-offs of listing any additional package versions or metadata before doing so.

heartsucker commented 7 years ago

Whoops. Sorry, y'all.

eloquence commented 4 years ago

The times we've had major issues with automatic upgrades, in practice, the SecureDrop version info alone has been sufficient to let us know that upgrades failed for some instances. For more granular information I do think there would be some concern that surfacing issues that only impact a specific package or component could give an adversary information that they can't otherwise infer.

For more granular failure modes, my inclination would be to try to make such failures (more) visible to the administrator first, who could then escalate them privately to us.