fix(ssh-capture): drop relay FIFO, rsyslog→/proc/1/fd/1 direct

The named pipe at /run/systemd/journal/syslog-relay had two problems
beyond its argv leak: any root-in-container process could (a) `cat`
the pipe and watch the live SIEM feed, and (b) write to it and inject
forged log lines. Since an attacker with a shell is already root
inside the honeypot, file permissions can't fix it.

Point rsyslog's auth/user actions directly at /proc/1/fd/1 — the
container-stdout fd Docker attached to PID 1 — and delete the
mkfifo + cat relay from the entrypoint. No pipe on disk, nothing to
read, nothing to inject, and one fewer cloaked process in `ps`.

templates/ssh/entrypoint.sh

@@ -31,15 +31,10 @@ ls /var/www/html
 HIST
 fi
 
-# Logging pipeline: named pipe → rsyslogd (RFC 5424) → stdout → Docker log capture.
-# Pipe lives under /run/systemd/journal/ and the relay process is cloaked via
-# exec -a so `ps aux` shows "systemd-journal-fwd" instead of a raw `cat`.
-mkdir -p /run/systemd/journal
-mkfifo /run/systemd/journal/syslog-relay
-
-bash -c 'exec -a "systemd-journal-fwd" cat /run/systemd/journal/syslog-relay' &
-
-# Start rsyslog (reads /etc/rsyslog.d/50-journal-forward.conf, writes to the pipe above)
+# Logging pipeline: rsyslogd (RFC 5424) → /proc/1/fd/1 → Docker log capture.
+# No intermediate pipe/relay — a named FIFO would be readable AND writable
+# by any root-in-container process, letting an attacker either eavesdrop on
+# the SIEM feed or inject forged log lines.
 rsyslogd
 
 # File-catcher: mirror attacker drops into host-mounted quarantine with attribution.