Bug 1519581

So I am confused. All of the avc's are listed as being allowed by the current policy but I don't ship some of those because they are as good as turning off selinux for nrpe. Is there some other policy installed with the MQSeriesGSKit-U8007 ? 

Usually for third party software like this, I would say you are going to have to craft changes to nrpe to make your environment work. Some of the changes as listed above would break security at other sites and so I don't think I can put them in without more information from a -v as exactly what the denial was

Hi Stephen,

Would information would you need? I don't believe there an additional policies shipped with MQSeriesGSKit-U8007.

If the policy is looking like its turning off SELinux any chance I get some guidance on crafting it a bit better. I am happy to close it out if isn't a bug.

Kind Regards
Nigel

Hi Stephen,

Would information would you need? I don't believe there an additional policies shipped with MQSeriesGSKit-U8007.

If the policy is looking like its turning off SELinux any chance I get some guidance on crafting it a bit better. I am happy to close it out if isn't a bug.

Kind Regards
Nigel

Well it may be ok for your system but not in general. I would look at doing a bit more detailed audit2allow to see what files exactly it is needing those permissions for. A lot of times they are for things which a specialized policy or chcon of files is needed which is only usable with the 3rd party software.

[root@el-7 ~]# audit2allow -av


#============= httpd_t ==============
# src="httpd_t" tgt="nagios_spool_t" class="file", perms="{ getattr open read }"
# comm="httpd" exe="" path="/var/log/nagios/status.dat"
#!!!! The file '/var/log/nagios/status.dat' is mislabeled on your system.  
#!!!! Fix with $ restorecon -R -v /var/log/nagios/status.dat
allow httpd_t nagios_spool_t:file { getattr open read };

This will help say what file exactly each file needs.

Thanks Stephen,

Here is the output, however it looks to me like that already all allowed. Is my understanding here correct?

#============= nrpe_t ==============
# src="nrpe_t" tgt="initrc_var_run_t" class="file", perms="{ lock open read }"
# comm="dspmq" exe="" path="/run/utmp"
#!!!! This avc is allowed in the current policy
allow nrpe_t initrc_var_run_t:file { lock open read };
# src="nrpe_t" tgt="nagios_etc_t" class="dir", perms="read"
# comm="nrpe" exe="" path=""
#!!!! This avc is allowed in the current policy
allow nrpe_t nagios_etc_t:dir read;
# src="nrpe_t" tgt="nrpe_etc_t" class="dir", perms="{ getattr search }"
# comm="nrpe" exe="" path=""
#!!!! This avc is allowed in the current policy
allow nrpe_t nrpe_etc_t:dir { getattr search };
# src="nrpe_t" tgt="pam_var_run_t" class="dir", perms="{ add_name write }"
# comm="sudo" exe="" path=""
#!!!! This avc is allowed in the current policy
allow nrpe_t pam_var_run_t:dir { add_name write };
# src="nrpe_t" tgt="pam_var_run_t" class="file", perms="{ create getattr lock open read write }"
# comm="sudo" exe="" path="/run/sudo/ts/nrpe"
#!!!! This avc is allowed in the current policy
allow nrpe_t pam_var_run_t:file { create getattr lock open read write };
# src="nrpe_t" tgt="unconfined_t" class="sem", perms="{ associate getattr read unix_read unix_write write }"
# comm="dspmq" exe="" path=""
#!!!! This avc is allowed in the current policy
allow nrpe_t unconfined_t:sem { associate getattr read unix_read unix_write write };
# src="nrpe_t" tgt="unconfined_t" class="shm", perms="{ associate getattr read unix_read unix_write write }"
# comm="dspmq" exe="" path=""
#!!!! This avc is allowed in the current policy
allow nrpe_t unconfined_t:shm { associate getattr read unix_read unix_write write };
# src="nrpe_t" tgt="unconfined_t" class="unix_stream_socket", perms="connectto"
# comm="runmqsc" exe="" path="/var/mqm/sockets/NPP!INF!QMGR/@app/spipe/npp-tst-mq-01/signalapp.00"
#!!!! This avc is allowed in the current policy
allow nrpe_t unconfined_t:unix_stream_socket connectto;
# src="nrpe_t" tgt="var_t" class="dir", perms="write"
# comm="amqxmsg0" exe="" path=""
#!!!! This avc is allowed in the current policy
allow nrpe_t var_t:dir write;
# src="nrpe_t" tgt="var_t" class="file", perms="{ execute getattr lock open read write }"
# comm="dspmq" exe="" path="/var/mqm/sockets/@SYSTEM/qmgrlocl/npp-tst-mq-01/1/Trace.shm"
#!!!! This avc is allowed in the current policy
allow nrpe_t var_t:file { execute getattr lock open read write };
# src="nrpe_t" tgt="var_t" class="sock_file", perms="write"
# comm="runmqsc" exe="" path=""
#!!!! This avc is allowed in the current policy
allow nrpe_t var_t:sock_file write;

So all of the items look like they are custom to the IBM software. I don't know why it is saying this avc is allowed in the current policy unless that policy you printed above was already inserted on the system. As far as I can tell none of the files would be things that I could put into a general nrpe policy are more of something that the IBM software would need to have with it. 

I am leaning towards not a bug but I don't like saying that without agreement from you on it.

Files like /run/sudo/ts/nrpe and /var/mqm/sockets/@SYSTEM/qmgrlocl/npp-tst-mq-01 aren't going to be things that the shipping version of nrpe deals with so I don't know how to add them in my end.

Hi Stephen,

No problems, I might have to raise question with IBM.

Should I ask them if they ship any SELinux polices for MQ, I gather that is what you are getting at.

If you don't think its a bug, then I am happy to close it out as not a bug. It does however seem strange to me that it doesn't honour the policy, perhaps that is just an IBM thing.

Kind Regards
Nigel

One of the things with selinux is that it is only going to know what to do what it has been 'taught' to do. [The same in many ways with selinux.] So the commands that the nrpe is being asked to use are ones that were not chcon to be used by nrpe probably because they set it up in a permissive mode or similar. [A lot of commercial software is only meant to work in permissive or no selinux. My favourite is various 3rd party auditing software which is to monitor selinux for the customer.. but well.. that is for other systems]

In general the companies may have a policy they use, but they will advise not ot have it or that each site needs to write their own (aka you are on your own, do not pass go, do not collect $200.00) I am going to keep this open for a bit longer. If IBM comes back and says that they are wanting to do something they can add stuff to this bug.

Thanks that does make sense.
I have raised the ticket with IBM, I will close this out next week based on the communication with IBM.

Thanks for the help.

Nigel, I have a 'not for general release' rule building and testing tool set that 'accretes' rules until no more AVC's are found, to get to a net effective rule set, and then monitors for new AVC's and alerts.  I run that part through /etc/cron.hourly/

It is really not 'ready for prime time, but I am willing to share it privately and upon condition of no further release.  Please let me know

I note that IBM seems to have SRPMs available -- are those under a FOSS amenable license, and also available from some public archive?

If so I can poke at it

Unfortunately the RPMs are no FOSS based, but they are available under a 90 day trial license period from here: https://www.ibm.com/developerworks/downloads/ws/wmq/index.html

We install our MQ servers as RPMs after you have accepted the license.

I am happy to test our the rule set on our test boxes to see if we any success.

Thanks for the help so far.

Kind Regards
Nigel

This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

The problem was with selinux policies for products Red Hat and Fedora do not ship. Policies for such binaries require either the product manufacturer or the site user to build as general policies may violate either of their needs.