Package: sslh Version: 2.1.4-1+b1 i am reporting an issue with the sslh package (version 2.1.4-1+b1) on Debian Unstable. When attempting to start the sslh service with the --transparent option included in the DAEMON_OPTS definition in /etc/default/sslh, the service fails to start immediately. The error message observed in 'journalctl -u sslh.service' is: cap_set_proc: Operation not permitted
This occurs despite the fact that running the /usr/sbin/sslh command manually with the exact same parameters from DAEMON_OPTS, as the 'sslh' user, works correctly. System Information: Distribution: Debian Unstable Kernel: Linux RA4 6.12.22-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.22-1 (2025-04-10) x86_64 GNU/Linux Systemd: systemd 257 (257.5-2) Relevant configuration files: Content of /etc/default/sslh: # cat /etc/default/sslh # Default options for sslh initscript # sourced by /etc/init.d/sslh # binary to use: forked (sslh) or single-thread (sslh-select) version # systemd users: don't forget to modify /lib/systemd/system/sslh.service DAEMON=/usr/sbin/sslh DAEMON_OPTS="--transparent -n --user sslh --listen 10.8.0.2:443 --listen 192.168.21.106:443 --ssh 192.168.21.106:2222 --ssl 192.168.21.106:4443 --openvpn 192.168.21.106:1194" Content of /etc/systemd/system/sslh.service: # cat /etc/systemd/system/sslh.service [Unit] Description=SSL/SSH multiplexer After=network.target Documentation=man:sslh(8) [Service] EnvironmentFile=/etc/default/sslh ExecStart=/usr/sbin/sslh --foreground $DAEMON_OPTS KillMode=process #Hardening #PrivateTmp=true AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_SETPCAP CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_SETPCAP #SecureBits=noroot-locked #ProtectSystem=strict #ProtectHome=true #ProtectKernelModules=true #ProtectKernelTunables=true #ProtectControlGroups=true #MountFlags=private #NoNewPrivileges=true #PrivateDevices=true #RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX #MemoryDenyWriteExecute=true #DynamicUser=true User=sslh Group=sslh [Install] WantedBy=multi-user.target Note: I have progressively commented out DynamicUser=true, NoNewPrivileges=true, SecureBits=noroot-locked, and nearly all other hardening directives for testing purposes. I have also explicitly added CAP_SETPCAP to AmbientCapabilities and CapabilityBoundingSet. Logs showing the failure: # journalctl -u sslh.service -f abr 26 10:37:49 RA4 systemd[1]: Started sslh.service - SSL/SSH multiplexer. abr 26 10:37:49 RA4 sslh[685714]: common.c:797: abr 26 10:37:49 RA4 sslh[685714]: common.c:797:cap_set_proc: Operation not permitted abr 26 10:37:49 RA4 systemd[1]: sslh.service: Main process exited, code=exited, status=1/FAILURE abr 26 10:37:49 RA4 systemd[1]: sslh.service: Failed with result 'exit-code'. abr 26 10:37:54 RA4 systemd[1]: Started sslh.service - SSL/SSH multiplexer. abr 26 10:37:54 RA4 sslh[685788]: common.c:797: abr 26 10:37:54 RA4 sslh[685788]: common.c:797:cap_set_proc: Operation not permitted abr 26 10:37:54 RA4 systemd[1]: sslh.service: Main process exited, code=exit Troubleshooting steps performed: 1. Confirmed manual execution of the sslh command with --transparent works correctly. 2. Checked SELinux status (appears inactive/command not found). 3. Checked AppArmor status (service is failed, not active). 4. Commented out DynamicUser=true in the service unit. 5. Commented out NoNewPrivileges=true in the service unit. 6. Commented out SecureBits=noroot-locked in the service unit. 7. Explicitly added CAP_SETPCAP to AmbientCapabilities and CapabilityBoundingSet in the service unit. 8. Commented out nearly all other hardening directives in the [Service] section. Conclusion: Despite these extensive troubleshooting steps, the 'cap_set_proc: Operation not permitted' error persists when starting sslh with --transparent as a systemd service. Given that manual execution works and standard security modules are not interfering, this strongly suggests a potential compatibility issue or a bug in the interaction between sslh (2.1.4), systemd, and the kernel regarding capability handling for non-root processes in the transparent mode. Thank you for your time and assistance.
