On Fri, 2007-01-19 at 15:05 +0000, Ted Rule wrote:
> 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@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@topaz ~]#
> [root@topaz ~]# pidof -x /usr/sbin/smartd
> 2871
> [root@topaz ~]# pidof -x smartd
> 2871
> [root@topaz ~]#
> [root@topaz ~]# pidof -c -x /usr/sbin/smartd
>
> [root@topaz ~]# pidof -c -x smartd
>
> [root@topaz ~]# run_init pidof -c -x /usr/sbin/smartd
> Authenticating root.
> Password:
>
> [root@topaz ~]#
> [root@topaz ~]# run_init pidof -x /usr/sbin/smartd
> Authenticating root.
> Password:
> 2871
> [root@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@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@topaz ~]# run_init ls -ldZ /proc/2871/exe
> Authenticating root.
> Password:
> lrwxrwxrwx root root system_u:system_r:fsdaemon_t /proc/2871/exe
> [root@topaz ~]#
>
> [root@topaz ~]# run_init ls -lZ /proc/2871/exe
> Authenticating root.
> Password:
> ls: /proc/2871/exe: Permission denied
>
> [root@topaz ~]# readlink /proc/2871/exec
> [root@topaz ~]#
>
> [root@topaz ~]# run_init readlink /proc/2871/exec
> Authenticating root.
> Password:
> [root@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 ?
Changes in the kernel (separate from selinux) altered permission
checking on proc such that ptrace checks are applied pervasively when
accessing another task's /proc/pid entries (this was done as part of the
containers work). Thus, policy has to allow ptrace permission between
the respective domains to support such accesses (and these are usually
covered up by dontaudit rules to suppress noise on e.g. ps -el and the
like).
In the future, I'd like to see proc permission checking revised to
distinguish read-only access to process state vs. full ptrace access.
--
Stephen Smalley
National Security Agency
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
