Privilege dropping

tlshd currently requires being executed as root: https://github.com/oracle/ktls-utils/blob/4d4045b9e34e83e66327cd0668013ab7bb78cd18/src/tlshd/config.c#L226

This is a lot of privilege, which OWASP describes as its second top risk: https://owasp.org/Top10/2025/A02_2025-Security_Misconfiguration/.

It'd be great if tlshd could run with fewer privileges.

Some ideas to reduce privilege:

1. Allow running as a non-privileged user, and document that the process must have CAP_NET_ADMIN, which is sufficient for the privileged netlink operations.
   • Perhaps keyring integration requires other capabilities, but I noticed tlshd seemed to work even without keyring integration. I don't know if that has security implications...
   • Implementation: Replace https://github.com/oracle/ktls-utils/blob/4d4045b9e34e83e66327cd0668013ab7bb78cd18/src/tlshd/config.c#L226 with getuid.
2. Hardening with namespaces/seccomp/landlock/etc.
   • The main goal being to limit CAP_NET_ADMIN, e.g. syscall filtering.
   • Implementation: systemd sandboxing. I have a working example.
   • systemd's RestrictAddressFamilies to AF_NETLINK prevent the process interfering with AF_INET or AF_UNIX.
   • SystemCallFilter to @system-service likely restricts some privileged syscalls.
3. Run each TLS handshake as an unprivileged user, in a privileged parent/unprivileged child model, similar to http://www.citi.umich.edu/u/provos/ssh/privsep.html * The benefit is that an unprivileged process is the one doing the parsing of the untrusted packets.
   • This might involve tlshd_service_socket doing a setuid/setgid to an unprivileged user, and then passing the handshake params to the parent (via SCM_RIGHTS), and having the parent call tlshd_genl_put_handshake_parms (which I guess is the thing that actually needs privilege). O
   • This could be fiddly.

I think a sweet spot is (1) and (2).

Start with src/tlshd/config.c at the root check, then inspect tlshd_service_socket and tlshd_genl_put_handshake_parms to identify which operations require privilege. Review the proposed systemd sandboxing approach and capability requirements before choosing an implementation path. Done means an agreed privilege-reduction design is implemented, its required capabilities or restrictions are documented, and tlshd still performs TLS handshakes.