dbus leaking file descriptors

[ldunston]

I recently installed the latest grsec patch 2.9.1 and linux kernel 3.2.51.

I'm running into a strange issue where the dbus-daemon is running into the max open files limit when grsec is enabled. Here's what I'm seeing:

The dbus subject produced from learning mode:
subject /bin/dbus-daemon o {
/
/bin h
/bin/dbus-daemon rx
/boot h
/dev h
/dev/null rw
/dev/urandom rxw
/etc rx
/etc/dbus-1 h
/etc/dbus-1/session.conf r
/etc/dbus-1/session.d
/etc/grsec h
/etc/gshadow h
/etc/gshadow- h
/etc/ppp h
/etc/samba/smbpasswd h
/etc/shadow h
/etc/shadow- h
/etc/ssh h
/lib
/lib/modules h
/lib/x86_64-linux-gnu rx
/lib64/modules h
/proc r
/proc/bus h
/proc/kallsyms h
/proc/kcore h
/proc/modules h
/proc/slabinfo h
/proc/sys h
/run h
/run/dbus/pid rwcdlL
/run/console/root rx
/run/dbus/system_bus_socket rxwcdlL
/selinux r
/sys h
/usr h
/usr/lib
/usr/share/dbus-1/services r
/usr/share/dbus-1/system-services rx
/var/backups h
/var/log h
+CAP_ALL
bind disabled
connect disabled
sock_allow_family all
}

root@server:/proc/12179# ls -l fd |wc -l
259

This count keeps increasing whenever a user ssh'es to the box and never decreases until dbus spins on a loop trying to get another FD

lsof shows a growing list of processes that no longer exist under /proc or in process table but have an open file

dbus-daem 12179 messagebus 102r REG 0,3 0 2651303205 /proc/24412/cmdline
dbus-daem 12179 messagebus 103r REG 0,3 0 2651303221 /proc/24437/cmdline
dbus-daem 12179 messagebus 104r REG 0,3 0 2651303237 /proc/24462/cmdline
dbus-daem 12179 messagebus 105r REG 0,3 0 2651303253 /proc/24487/cmdline
dbus-daem 12179 messagebus 106r REG 0,3 0 2651303269 /proc/24512/cmdline
dbus-daem 12179 messagebus 107r REG 0,3 0 2651303285 /proc/24537/cmdline
dbus-daem 12179 messagebus 108r REG 0,3 0 2651303301 /proc/24562/cmdline
dbus-daem 12179 messagebus 109r REG 0,3 0 2651303317 /proc/24587/cmdline
dbus-daem 12179 messagebus 110r REG 0,3 0 2651303333 /proc/24612/cmdline

Any ideas as to why this is happening?

Thanks,
Les

[ldunston]

More clues to the puzzle. With grsec disabled, /proc/<ssh pid>/cmdline is populated. With grsec enabled, that file doesn't seem to be written. The file is created but it's empty. Here is a strace of the dbus-daemon:


Grsec disabled:

poll([{fd=3, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}, {fd=1265, events=POLLIN}, {fd=1472, events=POLLIN}, {fd=1580, events=POLLIN}], 8, 29999) = 1 ([{fd=1580, revents=POLLIN}])
read(1580, "BEGIN\r\nl\1\0\1\0\0\0\0\1\0\0\0n\0\0\0\1\1o\0\25\0\0\0/"..., 2048) = 135
geteuid() = 102
access("/var/run/console/root", F_OK) = -1 ENOENT (No such file or directory)
open("/proc/2631/cmdline", O_RDONLY) = 1591
read(1591, "sshd: ldunston [priv]", 50) = 21
close(1591) = 0

Grsec enabled:

poll([{fd=3, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}, {fd=1265, events=POLLIN}, {fd=1472, events=POLLIN}, {fd=1580, events=POLLIN}], 8, 29999) = 1 ([{fd=1580, revents=POLLIN}])
read(1580, "BEGIN\r\nl\1\0\1\0\0\0\0\1\0\0\0n\0\0\0\1\1o\0\25\0\0\0/"..., 2048) = 135
geteuid() = 102
access("/var/run/console/root", F_OK) = -1 ENOENT (No such file or directory)
open("/proc/2977/cmdline", O_RDONLY) = 1591
read(1591, "", 50) = 0

[ldunston]

So the work around for now is to increase the max open files for dbus and install cronjobs to restart dbus every 10 minutes. Not very pretty but it's effective.

[ldunston]

OK, I found the real issue. The sshd subject had the d attribute turned on which appears to silently block.

http://en.wikibooks.org/wiki/Grsecurity ... ject_Modes

Guess I should read the docs more closely. Hopefully this helps someone else...