The initial sympom was when my Apache RSA/ACE module started always thinking that it was already running even if it wasn't.. preventing the service from working.. That program appears to run the following command to check (this is from a 'strings' on the binary - source isn't available): grep aceapi_rpc_server /proc/*/cmdline | sed 's/\/cmdline.*\/proc\// /g' | sed 's/\/cmdline.*/ /' | sed 's/.*\/proc\// /' | sort -u Now, aceapi_rpc_server perms are 4700, owner is nobody .. so, digging, I find that if I create a copy of the 'cat' binary and set the perms the same, it produces vastly less output than a non-suid binary.. This behavior is NOT present in 2.4.18-26.7 To see what I mean: (all commands run as root) cp /bin/cat /tmp/cat chown nobody /tmp/cat chmod 4700 /tmp/cat cat /proc/*/cmdline | wc /tmp/cat /proc/*/cmdline | wc rm -f /tmp/cat Try this on both kernel versions obviously. As long as that binary is set suid to a non-root user, this behavior will show up. Expected: [root@arf /root]# cat /proc/*/cmdline | wc 4 13 4365 [root@arf /root]# /tmp/!! /tmp/cat /proc/*/cmdline | wc 4 13 4375 Actual: [1:syslog] [~] > cat /proc/*/cmdline | wc 0 1 2119 [1:syslog] [~] > /tmp/!! /tmp/cat /proc/*/cmdline | wc 0 1 518
I'm prioritizing high/high for now because I can't run my apache server under the latest kernel, and backing down to an earlier rev leaves me open to the local root compromise.
Are you guys looking at this? When should I expect to work with someone, if at all? I'd just like to have my expectations set. Thanks -
The behaviour change was a security fix. The newest errata relax the rules slightly based on further auditing.