The officially official Devuan Forum!

edrusb

Member

Registered: 2021-08-03

Posts: 3  

[SOLVED] weird behavior for sslh

Hi,

I'm adding apparmor to sslh daemon and get the Devuan provided binary requesting cap_override capabilities at startup. Though I cannot find the corresponding system call in the source code... and thus cannot find any explanation to what seems to be an unnecessary requirement, bug, or worse a vulnerability and maybe a backdoor:

with apparmor refusing to give the cap_override capability to sslh:

root@mercure:/etc/apparmor.d# rmdir /run/sslh
root@mercure:/etc/apparmor.d# /etc/init.d/sslh start
[....] Starting ssl/ssh multiplexer: sslh/run/sslh/sslh.pid: Permission denied
. ok
root@mercure:/etc/apparmor.d# ls -al /run/sslh
total 0
drwxr-xr-x  2 sslh sslh  40 Aug  3 22:23 .
drwxr-xr-x 19 root root 780 Aug  3 22:23 ..
root@mercure:/etc/apparmor.d#

if making /run/sslh word writable...

root@mercure:/etc/apparmor.d# chmod a+rwx /run/sslh
root@mercure:/etc/apparmor.d# ls -al /run/sslh
total 0
drwxrwxrwx  2 sslh sslh  40 Aug  3 22:27 .
drwxr-xr-x 19 root root 780 Aug  3 22:27 ..
root@mercure:/etc/apparmor.d# /etc/init.d/sslh start
[ ok ] Starting ssl/ssh multiplexer: sslh.
root@mercure:/etc/apparmor.d# ls -al /run/sslh
total 4
drwxrwxrwx  2 sslh sslh  60 Aug  3 22:27 .
drwxr-xr-x 19 root root 780 Aug  3 22:27 ..
-rw-r--r--  1 root root   6 Aug  3 22:27 sslh.pid
root@mercure:/etc/apparmor.d#

... sslh created an sslh.pid as root user! As if root user needed any permission to create a file!?! let's double check:

root@mercure:/etc/apparmor.d# cd /run/sslh/
root@mercure:/run/sslh# ls -al
total 0
drwxr-xr-x  2 sslh sslh  40 Aug  3 22:29 .
drwxr-xr-x 19 root root 780 Aug  3 22:29 ..
root@mercure:/run/sslh# touch hello.world
root@mercure:/run/sslh# ls -al
total 0
drwxr-xr-x  2 sslh sslh  60 Aug  3 22:29 .
drwxr-xr-x 19 root root 780 Aug  3 22:29 ..
-rw-r--r--  1 root root   0 Aug  3 22:29 hello.world

Thus, no, root does not require any specific permission to create a file. But what is the most weird thing is when passing apparmor in complain mode to see the what permission was refused:

root@mercure:/etc/apparmor.d# /etc/init.d/sslh stop
[ ok ] Stopping ssl/ssh multiplexer: sslh.
root@mercure:/etc/apparmor.d# rm -rf /run/sslh
root@mercure:/etc/apparmor.d# aa-complain sslh
Setting /usr/sbin/sslh to complain mode.
root@mercure:/etc/apparmor.d# /etc/init.d/sslh start
[ ok ] Starting ssl/ssh multiplexer: sslh.
root@mercure:/etc/apparmor.d#
root@mercure:/etc/apparmor.d# dmesg | grep audit:
[11140.343915] audit: type=1400 audit(1628022719.260:86): apparmor="ALLOWED" operation="capable" profile="/usr/sbin/sslh" pid=24408 comm="sslh" capability=1  \
capname="dac_override"

IMHO, it is really weird to fail to create a file as root and pretend that CAP_DAC_OVERRIDE is required for that...

Worse, if looking at the source code, I cannot find any corresponding system call:

vm ~ >apt-get source sslh
...
vm ~ >cd sslh-1.18/
vm ~/tmp/sslh-1.18 >find . -type f -exec grep CAP_DAC_OVERRIDE {} \;
vm ~/tmp/sslh-1.18 >

I'm lost... any idea about the reason I cannot find any system call in the sslh source code and why the binary requires it?

Thanks for any help!
Cheers
Edrusb

edrusb

Member

Registered: 2021-08-03

Posts: 3  

Re: [SOLVED] weird behavior for sslh

OK, there is no problem:

The reason of this behavior is outside sslh code but to be found in the /etc/init.d/sslh script that run sslh. If the /var/run/sslh (/run/sslh in fact) directory does not exist, it is created by this script and is given the sslh user and group ownership with permission 0750.

The sslh daemon is then started: What it does very early is to write its PID in the /var/run/sslh/sslh.pid file as root user. But as the parent directory (/var/run/sslh) is not owned by root nor root is member of sslh group, the fact to open the sshd.pid file from a root process, triggers the use of dac_override capability as root has in theory not the right to create a file due to the permissions set by the /etc/init.d/sslh script. Where from the complain from apparmor. Thus, there is no need for the process to explicitly request that capability, where from my inability to find it in the source code.

Right after that the process drops root ownership (if instructed to do so with the --user argument) and the process has no more any specific capability, there is thus no security issue here.