TapTap/FastSync
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 2 Wiki Activity

fix(a7-3/s1): fail closed on non-loopback peers; require plaintext opt-in before challenge

Browse Source 
utils_fd_peer_is_local now returns true only when getpeername SUCCEEDS and the
peer address classifies as loopback. A non-socket descriptor (pipe/socketpair)
or any getpeername error is NOT local, so the daemon auth gate fails closed
instead of treating an untestable --stdio pipe as trusted (daemon auth modules
are --daemon-only and the stdio path never loads a daemon config).

server_module_gate now requires --allow-unauthenticated for the loopback
plaintext auth path: a plaintext loopback connection without the operator
opt-in is refused at the config gate BEFORE server_auth_handshake, so no SCRAM
challenge is sent. Remote peers still require verified TLS regardless of the
flag; the handler keeps its defense-in-depth checks.

Docs state the exact policy (verified TLS with matching --client-cn, or
operator-opted-in loopback plaintext), drop the SSH/stdio auth-transport claim
(they are daemon-only), and add the loopback trust-boundary relay caveat and
the CN-only (no SAN) residual. Adds a unit-test negative for pipe/socketpair
and an integration test where a relay observes no challenge when the flag is
absent.
This commit is contained in:
TapTap
2026-09-12 19:18:29 +02:00
parent a7a1930e88
commit d53614d06b
7 changed files with 99 additions and 29 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+20 -9
View File
@@ -528,15 +528,26 @@ restart-gated enumeration channel remains (persisting a dummy key is out of
scope); and the store iteration count is observable pre-auth by design, since
the miss path must match a hit.
An `auth users` module only accepts credentials over an encrypted, verified TLS
connection whose client certificate matches the server's `--client-cn`, or over
a local/SSH transport (a loopback TCP peer or the `--stdio` pipe). A remote
plaintext peer is refused before any challenge is sent, and
`--allow-unauthenticated` does **not** relax this: that flag only relaxes the
standalone plaintext gate. Clients sending daemon credentials with
`--password-file` to a non-loopback daemon must therefore use `--tls`; the
client rejects a non-local plaintext credential destination before any network
I/O.
An `auth users` module accepts credentials only when one of two conditions
holds: (a) the connection is an encrypted, verified TLS connection whose client
certificate matches the server's `--client-cn`, or (b) the connection is
plaintext from a loopback peer **and** the operator explicitly passed
`--allow-unauthenticated`. A remote plaintext peer is refused before any
challenge is sent, and `--allow-unauthenticated` never permits remote plaintext
auth: remote peers still require verified TLS regardless of the flag. Clients
sending daemon credentials with `--password-file` to a non-loopback daemon must
therefore use `--tls`; the client rejects a non-local plaintext credential
destination before any network I/O. Daemon modules are a `--daemon`-only
feature: the SSH `--stdio` path never loads a daemon config and is not an auth
transport for them.
Because the loopback allowance trusts whichever peer the kernel reports as
`127.0.0.1`, it assumes nothing relays remote connections to the daemon. A local
TCP forwarder or a TLS-terminating proxy in front of an auth-module listener
makes remote clients appear as loopback and bypasses the mutual-TLS identity
check, so do not front an auth-module listener with such a relay. Note also that
`--client-cn` matches the certificate's CN only (not a subjectAltName), which is
acceptable for a private CA.
TLS provides encrypted TCP transport. Supplying `--ca` enables certificate
verification; without it, traffic is encrypted but peer identity is not