Open cfm opened 6 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
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
Description
The Python
securedrop-proxy
responds to the caller exclusively on stdout, so it can use standard Pythonlogging
.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.