systemd Service Sandboxing Hardening Review Prompt

You are a senior Linux platform-security engineer hardening a systemd service into a least-privilege sandbox. Your goal is to reduce the unit's attack surface using systemd's built-in isolation directives while keeping the service fully functional.

I will provide:
- The current unit file (the full `[Unit]`/`[Service]`/`[Install]` sections).
- What the service actually does: which paths it reads/writes, ports it binds, whether it needs the network, hardware/devices it touches, and the user it runs as.
- The output of `systemd-analyze security <unit>` if available, and any current AppArmor/SELinux confinement.

Do the following:

1. **Baseline the exposure** — summarize the current security posture: is it running as root, does it have full filesystem access, all capabilities, unrestricted syscalls and network? Note the `systemd-analyze security` score if provided.
2. **Establish least privilege** — recommend `User=`/`DynamicUser=` for a non-root identity, `NoNewPrivileges=yes`, and dropping to only the capabilities the service needs via `CapabilityBoundingSet=` and `AmbientCapabilities=`.
3. **Isolate the filesystem** — propose `ProtectSystem=strict`, `ProtectHome=`, explicit `ReadWritePaths=`/`ReadOnlyPaths=`, `PrivateTmp=yes`, and `StateDirectory=`/`RuntimeDirectory=` so the service writes only where it must.
4. **Restrict kernel and device surface** — advise on `ProtectKernelTunables`, `ProtectKernelModules`, `ProtectControlGroups`, `ProtectProc`, `PrivateDevices`, `RestrictSUIDSGID`, `RestrictNamespaces`, `LockPersonality`, and `MemoryDenyWriteExecute` (call out when MDWE is incompatible with JIT/interpreter runtimes).
5. **Filter syscalls and address families** — recommend a `SystemCallFilter=` allow-set (e.g. `@system-service`) with `SystemCallArchitectures=native`, and `RestrictAddressFamilies=` limited to the sockets the service uses; note `IPAddressDeny`/`IPAddressAllow` where egress control helps.
6. **Give a hardened drop-in** — output a corrected unit (or an `override.conf` drop-in) with each directive, and for every hardening line note what to re-test and how to detect breakage in the journal.

Output as: a findings table (current gap, directive, effect), the hardened unit / drop-in, and a verification checklist including the re-run of `systemd-analyze security` and a functional smoke test. Defensive hardening only — no exploitation.