Bug 1145886

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;

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

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.

(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

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?

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

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

(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.

(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.

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?

(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.

(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?

(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.

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

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

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!

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.

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.

(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?

(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

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