1145886 – SELinux: keepalived killall denials

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1145886 - SELinux: keepalived killall denials

Summary: SELinux: keepalived killall denials

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	selinux-policy
Sub Component:
Version:	7.0
Hardware:	All
OS:	Linux
Priority:	high
Severity:	high
Target Milestone:	rc
Target Release:	---
Assignee:	Miroslav Grepl
QA Contact:	Milos Malik
Docs Contact:
URL:
Whiteboard:
Depends On:	1158114
Blocks:
TreeView+	depends on / blocked

Reported:	2014-09-24 04:53 UTC by Richard Su
Modified:	2015-08-25 18:12 UTC (History)
CC List:	11 users (show)
Fixed In Version:	selinux-policy-3.13.1-9.el7
Doc Type:	Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:	2015-03-05 10:41:13 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)
audit.log from overcloud-control node (300.90 KB, application/x-gzip) 2014-09-24 04:53 UTC, Richard Su	no flags	Details
View All

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Launchpad	1373932	0	None	None	None	Never
Red Hat Product Errata	RHBA-2015:0458	0	normal	SHIPPED_LIVE	selinux-policy bug fix and enhancement update	2015-03-05 15:17:00 UTC

Description Richard Su 2014-09-24 04:53:45 UTC

Created attachment 940666 [details]
audit.log from overcloud-control node

Description of problem:
After keepalived is started up, many killall denials are logged.

Version-Release number of selected component (if applicable):
openstack-selinux-0.5.15-1.el7ost.noarch
selinux-policy-3.12.1-153.el7_0.10.noarch
selinux-policy-targeted-3.12.1-153.el7_0.10.noarch
keepalived-1.2.10-2.el7.x86_64

How reproducible:
always

Steps to Reproduce:
1. Deploy ovecloud node using instack-undercloud

Actual results:
killall denials logged.

Expected results:
No killall denials logged.

Additional info:

cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 7.0 (Maipo)

cat /etc/keepalived/keepalived.conf 
vrrp_script chk_haproxy {
      script "killall -0 haproxy"
      interval 2
      weight 2
}

vrrp_instance VI_1 {
      interface br-ex
      state MASTER
      virtual_router_id 51
      priority 101 # 101 on master, 100 on backup
      virtual_ipaddress {
           192.0.2.6 dev br-ex
           192.0.2.7 dev br-ex
      }
      track_script {
           chk_haproxy
      }
}

Comment 2 Ryan Hallisey 2014-09-25 17:58:43 UTC

domain_read_all_domains_state(keepalived_t)
allow keepalived_t haproxy_t:process signull;
allow keepalived_t self:capability kill;

#============= rabbitmq_beam_t ==============
allow rabbitmq_beam_t rabbitmq_var_lib_t:lnk_file read;

#============= rhsmcertd_t ==============
allow rhsmcertd_t rpm_var_lib_t:dir { write add_name };
allow rhsmcertd_t rpm_var_lib_t:file create;

Comment 3 Ryan Hallisey 2014-09-25 17:59:35 UTC

That takes care of all the AVCs.  Mirek let me know what you think.

Comment 4 Miroslav Grepl 2014-09-26 11:13:51 UTC

So you can define whatever in /etc/keepalived/keepalived.conf and keepalived is going to execute it. 

It would be fine to have it in scripts with a location. We could add a transition to keepalived_unconfined_script_t for example.

Comment 5 Giulio Fidente 2014-09-26 11:17:26 UTC

(In reply to Ryan Hallisey from comment #2)
> domain_read_all_domains_state(keepalived_t)
> allow keepalived_t haproxy_t:process signull;
> allow keepalived_t self:capability kill;

also:
 
> #============= rabbitmq_beam_t ==============
> allow rabbitmq_beam_t rabbitmq_var_lib_t:lnk_file read;
 
should not be needed, it is caused by how we deploy things and should have been fixed by some custom policy we added, see https://bugs.launchpad.net/tripleo/+bug/1373145

> #============= rhsmcertd_t ==============
> allow rhsmcertd_t rpm_var_lib_t:dir { write add_name };
> allow rhsmcertd_t rpm_var_lib_t:file create;

even though there could be issues in the audit.log , I think this is not related to the bug

Comment 6 Miroslav Grepl 2014-09-26 13:39:24 UTC

cat /etc/keepalived/keepalived.conf 
vrrp_script chk_haproxy {
      script "killall -0 haproxy"
      interval 2
      weight 2
}

vrrp_instance VI_1 {
      interface br-ex
      state MASTER
      virtual_router_id 51
      priority 101 # 101 on master, 100 on backup
      virtual_ipaddress {
           192.0.2.6 dev br-ex
           192.0.2.7 dev br-ex
      }
      track_script {
           chk_haproxy
      }
}

is this by default in distro?

Comment 7 Giulio Fidente 2014-09-26 13:51:56 UTC

it is not precisely the default but some samples shipped with keepalived make use of 'killall -0', eg: /usr/share/doc/keepalived/keepalived.conf.vrrp.localcheck

Comment 8 Miroslav Grepl 2014-09-29 14:02:10 UTC

Any chance to move this functionality from the config file to script files?

Comment 9 Ryan O'Hara 2014-09-29 14:07:41 UTC

(In reply to Miroslav Grepl from comment #8)
> Any chance to move this functionality from the config file to script files?

What functionality are you asking about? Moving "killall -0 haproxy" to an actual script rather than just specifying the command in keepalived.conf? You can do that now.

Comment 10 Miroslav Grepl 2014-09-30 07:58:07 UTC

(In reply to Ryan O'Hara from comment #9)
> (In reply to Miroslav Grepl from comment #8)
> > Any chance to move this functionality from the config file to script files?
> 
> What functionality are you asking about? Moving "killall -0 haproxy" to an
> actual script rather than just specifying the command in keepalived.conf?
> You can do that now.

Yes. We would need to have 

/usr/lib/keepalived/scripts 

for example which would need to be a part of keepalived rpm payload.

Then we could label them as keepalived_unconfined_script_exec_t and have

keepalived_t @keepalived_unconfined_script_exec_t -> keepalived_unconfined_script_t

The point is you can define whatever and we don't want to allow it by default for keepalived_t.

Comment 11 Giulio Fidente 2014-09-30 12:13:43 UTC

I am afraid but from the samples it seems one can have multiple vrrp_script definitions in the keepalived config where each is used for a different purpose so making it a *single* script would not cover all use cases. Not sure if it would still be possible maybe by using a special directory as a container for the scripts?

Comment 12 Ryan O'Hara 2014-09-30 17:19:24 UTC

(In reply to Giulio Fidente from comment #11)
> I am afraid but from the samples it seems one can have multiple vrrp_script
> definitions in the keepalived config where each is used for a different
> purpose so making it a *single* script would not cover all use cases. Not
> sure if it would still be possible maybe by using a special directory as a
> container for the scripts?

This is exactly what Miroslav proposed in comment #10.

Comment 13 Ryan O'Hara 2014-09-30 17:23:09 UTC

(In reply to Miroslav Grepl from comment #10)
> (In reply to Ryan O'Hara from comment #9)
> > (In reply to Miroslav Grepl from comment #8)
> > > Any chance to move this functionality from the config file to script files?
> > 
> > What functionality are you asking about? Moving "killall -0 haproxy" to an
> > actual script rather than just specifying the command in keepalived.conf?
> > You can do that now.
> 
> Yes. We would need to have 
> 
> /usr/lib/keepalived/scripts 
> 
> for example which would need to be a part of keepalived rpm payload.
> 
> Then we could label them as keepalived_unconfined_script_exec_t and have
> 
> keepalived_t @keepalived_unconfined_script_exec_t ->
> keepalived_unconfined_script_t
> 
> The point is you can define whatever and we don't want to allow it by
> default for keepalived_t.

OK. But these are not predefined scripts. I'm guessing you know this. So the solution here is to create an empty directory at install time and then document that users should put all scripts in this directory? Will users be required to run restorecon once the scripts have been created?

Comment 16 Miroslav Grepl 2014-10-02 08:35:36 UTC

(In reply to Ryan O'Hara from comment #13)
> (In reply to Miroslav Grepl from comment #10)
> > (In reply to Ryan O'Hara from comment #9)
> > > (In reply to Miroslav Grepl from comment #8)
> > > > Any chance to move this functionality from the config file to script files?
> > > 
> > > What functionality are you asking about? Moving "killall -0 haproxy" to an
> > > actual script rather than just specifying the command in keepalived.conf?
> > > You can do that now.
> > 
> > Yes. We would need to have 
> > 
> > /usr/lib/keepalived/scripts 
> > 
> > for example which would need to be a part of keepalived rpm payload.
> > 
> > Then we could label them as keepalived_unconfined_script_exec_t and have
> > 
> > keepalived_t @keepalived_unconfined_script_exec_t ->
> > keepalived_unconfined_script_t
> > 
> > The point is you can define whatever and we don't want to allow it by
> > default for keepalived_t.
> 
> OK. But these are not predefined scripts. I'm guessing you know this. So the
> solution here is to create an empty directory at install time and then
> document that users should put all scripts in this directory?
Yes. 
> Will users be
> required to run restorecon once the scripts have been created?

No need if it is a part of payload. Then rpm will label it during install phase and if a user creates a script then it will inherit labeling from the dir.

Comment 17 Richard Su 2014-10-07 16:13:13 UTC

Ryan, are you making the changes to the keepalived package to support the directory for dropping scripts?

Comment 19 Ryan O'Hara 2014-10-27 15:02:05 UTC

I did some work on this today for Fedora which has the same problem. I propose we create /usr/libexec/keepalived directory per recommendations in [1]. Scripts placed here would look like this:

#/bin/bash
killall -0 haproxy
exit $?

Or you could use systemctl is-actice to accomplish the same thing, which is probably a bit better:

#/bin/bash
systemctl -q is-active haproxy
exit $?

Both seem to work as expected.

[1] http://fedoraproject.org/wiki/Packaging:Guidelines#Libexecdir

Comment 20 Ryan O'Hara 2014-10-27 15:03:46 UTC

Miroslav, do we need a new BZ for selinux-policy to cover the work that needs to happen there? Assuming I just need tp provided you with the path where scripts will live (/usr/libexec/keepalived) and you'll take care of the labelling. Thanks!

Comment 23 Miroslav Grepl 2014-11-03 10:02:18 UTC

commit 976668e8222d0cc08958ba560c65d3d21348825b
Author: Miroslav Grepl <mgrepl>
Date:   Mon Nov 3 11:00:08 2014 +0100

    Add suppor for keepalived unconfined scripts and allow keepalived to read all domain state and kill capability.

Comment 24 John Horne 2014-11-04 01:26:05 UTC

I am seeing the same type of problem on RHEL 6.6. Our vrrp 'scripts' use pgrep rather than killall though. May I ask that the changes in comment #23 are backported to 6.6 as well please. Thanks.

Comment 25 Miroslav Grepl 2014-11-04 07:14:56 UTC

(In reply to John Horne from comment #24)
> I am seeing the same type of problem on RHEL 6.6. Our vrrp 'scripts' use
> pgrep rather than killall though. May I ask that the changes in comment #23
> are backported to 6.6 as well please. Thanks.

Could open a new bug for RHEL6?

Comment 30 John Horne 2015-01-26 12:24:45 UTC

(In reply to Miroslav Grepl from comment #25)
> (In reply to John Horne from comment #24)
> > I am seeing the same type of problem on RHEL 6.6. Our vrrp 'scripts' use
> > pgrep rather than killall though. May I ask that the changes in comment #23
> > are backported to 6.6 as well please. Thanks.
> 
> Could open a new bug for RHEL6?

This has been done as Bug #1158115

Comment 32 errata-xmlrpc 2015-03-05 10:41:13 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-0458.html

Note You need to log in before you can comment on or make changes to this bug.