Privilege dropping

[tomfitzhenry]

tlshd currently requires being executed as root:

ktls-utils/src/tlshd/config.c

Line 226 in 4d4045b

#define TLSHD_OWNER 0 /* root */

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

     ktls-utils/src/tlshd/config.c

     Line 226 in 4d4045b

     #define TLSHD_OWNER 0 /* root */

     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).

[chucklever]

The TLSHD_OWNER refers to the UID owner of tlshd's configuration files. It's not used for setting execution privilege.

By default, keyrings are set up but are not used in basic configurations, and that's probably why things "just worked" for you. But they are used extensively with NVMe and its PSK authentication. tlshd will need to access and add items to keyrings during operation in some configurations.

I worked with Niels while at CITI so I trust his ideas; idea 3 appeals, but running the parent and children under the same (lowered) privilege level is probably the simplest overall. We will need the children processes to do netlink and keyring operations in addition to setsockopt with SOL_TLS .

Idea 2 sounds like it can add extra configuration and dependencies on security packages. OTOH we might not have much choice if the most common deployment configuration for system daemons is to wrap them with systemd sandboxing.

Probably the first thing to do here is take a poll of popular distros to see how they would prefer this to be handled.

[chucklever]

We at least need to document (in tlshd man pages or other documents) what privileges and capabilities tlshd and its libraries require.

[chucklever]

RHEL might prefer SELinux.

[tomfitzhenry]

The TLSHD_OWNER refers to the UID owner of tlshd's configuration files. It's not used for setting execution privilege.

Ah, my bad!

running the parent and children under the same (lowered) privilege level is probably the simplest overall

Yes, I agree.

FWIW, in NixOS/nixpkgs#508462 I am adding support for tlshd in NixOS, including a CI integration test that sets up tlshd on client/server and checks nfs access with xprtsec=mtls works. tlshd runs as a normal user in the test.