rsyslog 100% cpu

[lesnoland]

this is not really a bug, but on default policy config it caused me a lot of trouble so i am posting this in case other people encouter this.

when you turn on RBAC, using default policy file which was shipped with the package (not learning), and if rsyslog is enabled it will go up to 100% CPU (it loops trying to write some logs i think) and stay there until you stop the service/kill the process.

the problem is even if you turn off RBAC, the process will still remain there with 100% CPU until you stop the service/kill the process.

the interesting thing is that its not rsyslog causing the problem but /bin/dd, adding:
subject /bin/dd
+CAP_SYS_ADMIN
will fix the problem.

i think this is true for other syslog daemons, like klogd, etc.

i found the following dd that causes the problem(i think):
root 7814 1 0 03:29 ? 00:00:00 dd bs=1 if=/proc/kmsg of=/var/run/rsyslog/kmsg

[biz]

when you turn on RBAC, using default policy file which was shipped with the package (not learning), and if rsyslog is enabled it will go up to 100% CPU (it loops trying to write some logs i think) and stay there until you stop the service/kill the process.

The "imklog" module needs read access for /proc/kmsg, that's the same reason why you can't drop privileges with rsyslog if you want kernel messages. The issue is known, the problem is handled badly (infinite loop trying to read from /proc/kmsg). See also http://wiki.rsyslog.com/index.php/Chroot_support#Problems

[spender]

I wouldn't recommend anyone add the subject to their policy from the original poster. Giving CAP_SYS_ADMIN to the dd binary to any root user (we have to assume an attacker) isn't a good idea. It'd be better to find out why it might need that privilege in certain circumstances and use nested subjects if it's necessary to run dd in such a way that it requires that privilege outside of the admin role.

-Brad