What is the AVC message you are seeing?

The issue can be reproduced with other running processes. This time I chose gam_server. As long as I'm using 'killall <full-path>' the process does not get killed. I don't see any AVC, which seems to deny the /proc/PID/exe read access, which is required by killall.

# id -Z
root:sysadm_r:sysadm_t:SystemLow-SystemHigh
# getenforce 
Enforcing
# semodule -DB
# date
Tue Feb 23 03:35:22 EST 2010
# ps -efZ | grep gam
system_u:system_r:rpm_t:SystemLow-SystemHigh root 2598 1  0 03:25 ?    00:00:00 /usr/libexec/gam_server
root:sysadm_r:sysadm_t:SystemLow-SystemHigh root 2770 2686  0 03:35 ttySG0 00:00:00 grep gam
# killall /usr/libexec/gam_server
/usr/libexec/gam_server: no process killed
# ps -efZ | grep gam
system_u:system_r:rpm_t:SystemLow-SystemHigh root 2598 1  0 03:25 ?    00:00:00 /usr/libexec/gam_server
root:sysadm_r:sysadm_t:SystemLow-SystemHigh root 2773 2686  0 03:35 ttySG0 00:00:00 grep gam
[root@altix4 ~]# ausearch -m AVC -ts 03:35:00 | audit2allow

#============= semanage_t ==============
allow semanage_t load_policy_t:process { siginh noatsecure rlimitinh };
allow semanage_t setfiles_t:process { siginh noatsecure rlimitinh };

#============= sysadm_t ==============
allow sysadm_t apmd_t:process ptrace;
allow sysadm_t audisp_t:process ptrace;
allow sysadm_t auditd_t:process ptrace;
allow sysadm_t automount_t:process ptrace;
allow sysadm_t avahi_t:process ptrace;
allow sysadm_t bluetooth_t:process ptrace;
allow sysadm_t crond_t:process ptrace;
allow sysadm_t cupsd_t:process ptrace;
allow sysadm_t dhcpc_t:process ptrace;
allow sysadm_t fsdaemon_t:process ptrace;
allow sysadm_t gpm_t:process ptrace;
allow sysadm_t hald_t:process ptrace;
allow sysadm_t init_t:process ptrace;
allow sysadm_t initrc_t:process ptrace;
allow sysadm_t irqbalance_t:process ptrace;
allow sysadm_t kernel_t:process ptrace;
allow sysadm_t klogd_t:process ptrace;
allow sysadm_t local_login_t:process ptrace;
allow sysadm_t ntpd_t:process ptrace;
allow sysadm_t pcscd_t:process ptrace;
allow sysadm_t portmap_t:process ptrace;
allow sysadm_t restorecond_t:process ptrace;
allow sysadm_t rpcd_t:process ptrace;
allow sysadm_t rpm_t:process ptrace;
allow sysadm_t semanage_t:process { siginh noatsecure rlimitinh };
allow sysadm_t sendmail_t:process ptrace;
allow sysadm_t setrans_t:process ptrace;
allow sysadm_t sshd_t:process ptrace;
allow sysadm_t syslogd_t:process ptrace;
allow sysadm_t system_dbusd_t:process ptrace;
allow sysadm_t udev_t:process ptrace;

After a discussion with mgrepl we found out that "setsebool allow_ptrace on" is needed to kill racoon process. If this conclusion is correct, we need to add "setsebool allow_ptrace on" command to following files:

/etc/sysconfig/network-scripts/ifup-ipsec
/etc/sysconfig/network-scripts/ifdown-ipsec

Current versions of ^^^ files are not able to kill the running instance of racoon.

No we do not want to set the boolean within the scripts.  I would like to gain access to this machine to see what the problem is.  

I think this is a kernel issue.

Allowing sysadm_t to ptrace on MLS machines is not a great idea.  The problem is the kernel is checking ptrace just to look at the proc entry.  I think this is changed in RHEL6, Eric?

Yes, it should have been fixed in RHEL6.

So the safest fix for MLS would be to change the killall to not include the path.

Created attachment 397343 [details]
Patch for the affected network scripts

This changes the affected network scripts to not use the full path in the killall call. The question is whether the pidof calls should not be replaced with calls without the full path too however pidof seems to work even if it can't read the /proc/<pid>/exe links.

Wait... why would the path make a difference?

I think the better answer would be to find a way to fix sysvinit so that killall behaves the same.

Bill, do you mean to fix the killall command in psmisc package?

I think that's the better solution, as other scripts might want it to work.

What's special about MLS that it fails when passed a full path?

There is a kernel issue where the kernel executes a ptrace check when a process runs a check on the path.  I think reading /proc/PID/exe causes a ptrace access.  If you do not state a path it only looks at the PID files.  Allowing all processes that run killall to ptrace in SELinux policy on an MLS box seems to be the wrong answer.  Fixing the kernel is the right answer, although might be the most complicated.

Since it is too late to address this issue in RHEL 5.5, it has been proposed for RHEL 5.6.  Contact your support representative if you need to escalate this issue.

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0075.html