freedomofpress / securedrop-client

a Qt-based GUI for SecureDrop journalists 📰🗞️
GNU Affero General Public License v3.0
41 stars 40 forks source link

log proxy events to syslog #1996

Open cfm opened 4 months ago

cfm commented 4 months ago

Description

The Python securedrop-proxy responds to the caller exclusively on stdout, so it can use standard Python logging.

The Rust securedrop-proxy in #1718 responds with a mix of stdout and stderr, so it's silent. In testing, this makes it difficult to tell whether it (or some other proxy instance on the machine...) is handling a given request.

It would be nice to log proxy events to syslog just for testing purposes.

How will this impact SecureDrop users?

No user-facing changes.

How would this affect the SecureDrop Workstation threat model?

No threat-model implications: the current proxy implementation already has this behavior.

User Stories

As a developer, I want to be able to watch a securedrop-proxy instance and see that it's handling requests.

cfm commented 4 months ago

When actually running via qrexec, it looks like we get logging of the headers of streamed responses for free since the proxy writes them via stderr, e.g.:

May  9 13:14:06 sd-proxy securedrop.Proxy+-sd-app: {"headers":{"etag":"sha256:79a993c0444c44547b1ce3a5420e545b508ddb3ccf67c2790c05b0b1a24a0323","content-length":"456","content-type":"application/pgp-encrypted","cache-control":"no-store","server":"Apache","last-modified":"Wed, 06 Mar 2024 19:41:06 GMT","content-disposition":"attachment; filename=1-scholastic_runner-up-msg.gpg","cross-origin-resource-policy":"same-origin","x-frame-options":"DENY","cross-origin-opener-policy":"same-origin","date":"Thu, 09 May 2024 20:14:03 GMT","x-content-type-options":"nosniff","content-security-policy":"default-src 'none'; script-src 'self'; style-src 'self'; img-src 'self'; font-src 'self'; frame-ancestors 'none';","cross-origin-embedder-policy":"same-origin","referrer-policy":"no-referrer"}}

What I (at least) really want is just request/response correlation (since they could be interleaved among securedrop-proxy invocations), e.g.:

<timestamp1> <UUID> <verb> <path> -> sent <n> bytes
...
<timestamp2> <UUID> <verb> <path> <- recv <n> bytes
legoktm commented 4 months ago

Hmm, I didn't realize that stderr over qrexec gets logged - I don't think that will leak anything super sensitive, but we should just keep in mind what ends up in headers.

https://docs.rs/syslog/latest/syslog/ looks reasonable to use, here's what the audit load looks like:

9 unvetted dependencies:
  deranged:0.3.11 missing ["safe-to-run"]
  error-chain:0.12.4 missing ["safe-to-run"]
  num_threads:0.1.7 missing ["safe-to-run"]
  powerfmt:0.2.0 missing ["safe-to-run"]
  syslog:6.1.1 missing ["safe-to-run"]
  time:0.3.36 missing ["safe-to-run"]
  time-macros:0.2.18 missing ["safe-to-run"]

recommended audits for safe-to-run:
    Command                                               Publisher  Used By            Audit Size
    cargo vet diff time-macros 0.2.10 0.2.9               jhpratt    time               5 files changed, 6 insertions(+), 8 deletions(-)
    cargo vet diff num_threads 0.1.6 0.1.7                jhpratt    time               5 files changed, 73 insertions(+), 71 deletions(-)
    cargo vet diff error-chain 0.11.0 0.12.4              AndyGauge  syslog             20 files changed, 604 insertions(+), 459 deletions(-)
    cargo vet inspect syslog 6.1.1                        Geal       securedrop-proxy   1148 lines
    cargo vet inspect powerfmt 0.2.0                      jhpratt    time and deranged  1623 lines
    cargo vet inspect deranged 0.3.10                     jhpratt    time               2611 lines
    cargo vet inspect time 0.3.36                         jhpratt    syslog             19205 lines