pidof -c fails under FC6/strict

[Ted Rule]

There appears to be a generic problem with "pidof -c" under SELinux
enforcing which has the side-effect of confusing some of the init.d
scripts.

In particular, the following services - at least - fail to shut down or
report status cleanly:

acpid
hidd
vsftpd
smartd
autofs
mcstrans
syslog-ng ( but not syslogd .. )

The common feature is that these daemons lack a corresponding
/var/run/<daemonname>.pid; in the case of syslog-ng, of course, the real
pid has the "wrong" name.

During shutdown, /etc/init.d/functions:killproc() searches for the
pidfile, and if it fails to find one, it searches for a pid with a
matching exec name via the __pids_pidof() function.

...
# Output PIDs of matching processes, found using pidof
__pids_pidof() {
        pidof -c -o $$ -o $PPID -o %PPID -x "$1" || \
                pidof -c -o $$ -o $PPID -o %PPID -x "${1##*/}"
}
...

When invoked in SELinux permissive, all is well, and the correct pid is
located, but under enforcing, ( selinux-policy-strict-2.4.6-27 in my
case), "pidof -c" returns a null string. This in turn, causes killproc
to assume that the service is dead.

FWIW, FC4/strict/enforcing is Ok where pidof has a -c option, whilst
RHEL4 doesn't appear to have a -c option to pidof anyway.

The latest pidof appears to use readlink() to compare the value
of /proc/<pid>/exe for any matching pids - older pidof's used stat().

Needless to say, logs don't show any AVC's when I try to run the rogue
pidof calls.

By way of example, one can read the basic process list from sysadm_t,
and then show that pidof -c -x fails where pidof -x works. Similarly,
I've used run_init to emulate the behaviour of the boot scripts running
pidof: 

[root at topaz ~]# ps axZ | grep smartd
system_u:system_r:fsdaemon_t     2871 ?        S
0:00 /usr/sbin/smartd -q never
staff_u:sysadm_r:sysadm_t        3375 pts/0    R+     0:00 grep smartd
[root at topaz ~]#
[root at topaz ~]# pidof -x /usr/sbin/smartd
2871
[root at topaz ~]# pidof -x smartd
2871
[root at topaz ~]#
[root at topaz ~]# pidof -c -x /usr/sbin/smartd

[root at topaz ~]# pidof -c -x smartd

[root at topaz ~]# run_init pidof -c -x /usr/sbin/smartd
Authenticating root.
Password:

[root at topaz ~]#
[root at topaz ~]# run_init pidof -x /usr/sbin/smartd
Authenticating root.
Password:
2871
[root at topaz ~]#

As a variant on these tests, I've tried to directly ls and readlink the
exe in question; ls fails to read the symlink and errors, whilst
readlink silently returns with a null.

[root at topaz ~]# ls -ldZ /proc/2871/exe
ls: cannot read symbolic link /proc/2871/exe: Permission denied
lrwxrwxrwx  root root system_u:system_r:fsdaemon_t     /proc/2871/exe
[root at topaz ~]# run_init ls -ldZ /proc/2871/exe
Authenticating root.
Password:
lrwxrwxrwx  root root system_u:system_r:fsdaemon_t     /proc/2871/exe
[root at topaz ~]#

[root at topaz ~]# run_init ls -lZ /proc/2871/exe
Authenticating root.
Password:
ls: /proc/2871/exe: Permission denied

[root at topaz ~]# readlink /proc/2871/exec
[root at topaz ~]#

[root at topaz ~]# run_init readlink /proc/2871/exec
Authenticating root.
Password:
[root at topaz ~]#

As a workround for the present, I've simply removed the -c option
from /etc/init.d/functions:__pids_pidof()

I'm currently running:

selinux-policy-strict-2.4.6-27.fc6
kernel-2.6.18-1.2869
SysVinit-2.86-14

Should this be logged as a bug under SELinux policy or SysVinit?

Does this bug affect targeted policy as well?

Is there some simple extra permission which could be granted to initrc_t
and sysadm_t which would let them perform readlink /proc/<pid>/exe, and
hence pidof -c ?


-- 
Ted Rule

Director, Layer3 Systems Ltd

W: http://www.layer3.co.uk/