Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1519581 - SELinux prevents nrpe running commands correctly
Summary: SELinux prevents nrpe running commands correctly
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: nrpe
Version: 28
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Stephen John Smoogen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-12-01 00:09 UTC by Nigel
Modified: 2018-07-24 20:49 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-07-24 20:49:38 UTC


Attachments (Terms of Use)
NRPE Policy created using audit2allow (deleted)
2017-12-01 00:09 UTC, Nigel
no flags Details

Description Nigel 2017-12-01 00:09:12 UTC
Created attachment 1361368 [details]
NRPE Policy created using audit2allow

Description of problem:
I am running RHEL 7.3 and have installed the nrpe and nrpe-selinux packages. I am running a custom python script which runs correctly when SELinux is turned off. The script is written for python 2.7.5 and calls IBM MQ Binaries to determine the result. I have used audit2allow and audit2why to generate and apply the SELinux policy, which unfortunately has not helped to solve the issue.


Version-Release number of selected component (if applicable):
/etc/nagios/plugins.d# repoquery -i nrpe

Name        : nrpe
Version     : 3.2.0
Release     : 6.el7
Architecture: x86_64
Size        : 364219
Packager    : Fedora Project
Group       : Applications/System
URL         : http://www.nagios.org
Repository  : epel
Summary     : Host/service/network monitoring agent for Nagios
Source      : nrpe-3.2.0-6.el7.src.rpm
Description :
Nrpe is a system daemon that will execute various Nagios plugins
locally on behalf of a remote (monitoring) host that uses the
check_nrpe plugin.  Various plugins that can be executed by the
daemon are available at:
http://sourceforge.net/projects/nagiosplug

/etc/nagios/plugins.d# repoquery -i nrpe-selinux

Name        : nrpe-selinux
Version     : 3.2.0
Release     : 6.el7
Architecture: x86_64
Size        : 9412
Packager    : Fedora Project
Group       : Applications/System
URL         : http://www.nagios.org
Repository  : epel
Summary     : SELinux context for nrpe
Source      : nrpe-3.2.0-6.el7.src.rpm
Description :
SElinux context for nrpe.

/etc/nagios/plugins.d# python
Python 2.7.5 (default, Aug  2 2016, 04:20:16)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.


IBM Packages which have been loaded into our repository.
/etc/nagios/plugins.d# repoquery -i MQSeriesServer-U8007-8.0.0-7.x86_64

Name        : MQSeriesServer-U8007
Version     : 8.0.0
Release     : 7
Architecture: x86_64
Size        : 67785586
Packager    : None
Group       : Applications/Networking
URL         : None
Repository  : indue-el7
Summary     : WebSphere MQ Server FileSet (Maintenance Pack U8007)
Source      : MQSeriesServer-U8007-8.0.0-7.src.rpm
Description :
IBM WebSphere MQ for Linux for x86_64
U8007

/etc/nagios/plugins.d# repoquery -i MQSeriesRuntime-U8007-8.0.0-7.x86_64

Name        : MQSeriesRuntime-U8007
Version     : 8.0.0
Release     : 7
Architecture: x86_64
Size        : 101756707
Packager    : None
Group       : Applications/Networking
URL         : None
Repository  : indue-el7
Summary     : WebSphere MQ Runtime FileSet (Maintenance Pack U8007)
Source      : MQSeriesRuntime-U8007-8.0.0-7.src.rpm
Description :
IBM WebSphere MQ for Linux for x86_64
U8007

/etc/nagios/plugins.d# repoquery -i MQSeriesGSKit-U8007-8.0.0-7.x86_64

Name        : MQSeriesGSKit-U8007
Version     : 8.0.0
Release     : 7
Architecture: x86_64
Size        : 22423992
Packager    : None
Group       : Applications/Networking
URL         : None
Repository  : indue-el7
Summary     : WebSphere MQ GSKit FileSet (Maintenance Pack U8007)
Source      : MQSeriesGSKit-U8007-8.0.0-7.src.rpm
Description :
IBM WebSphere MQ for Linux for x86_64
U8007

How reproducible:
This occurs when SELinux is enabled and NRPE issues a command using the MQ Binaries.

Steps to Reproduce:
1. Install NRPE
2. Run MQ binaries in a script to display the queue managers
3. Observe invalid output.

Actual results:
Below is the process being used.

Nagios server running command:
[nagios@nagios01-prod 09:28:57] ~
$ /usr/lib64/nagios/plugins/check_nrpe  -H tst-mq-01.domain -p 5666 -t 30 -c queuedepth -a INF.QMGR
UNKNOWN: Queue Manager: INF.QMGR unknown.

Client side ( to simply I am using a bash script which display the same behavior)
nrpe check config: /etc/nagios/nrpe.d# cat nrpe_queuedepth.cfg
command[queuedepth]=/etc/nagios/plugins.d/get-queue-depth.sh -m $ARG1$

[09:59:49] root@tst-mq-01
/etc/nagios/plugins.d# cat get-queue-depth.sh
#!/bin/bash
/opt/mqm/bin/dspmq
exit 0

[09:59:52] root@tst-mq-01
/etc/nagios/plugins.d# getenforce
Enforcing

[10:00:18] root@tst-mq-01
/etc/nagios/plugins.d# setenforce 0

[10:00:28] root@tst-mq-01
/etc/nagios/plugins.d# getenforce
Permissive

Run the check again on the server with SELinux set to permissive.

[10:01:45] root@tst-mq-01
/etc/nagios/nrpe.d# service nrpe restart
Redirecting to /bin/systemctl restart  nrpe.service

Expected results:
$ /usr/lib64/nagios/plugins/check_nrpe -H tst-mq-01.domain -p 5666 -t 30 -c queuedepth -a INF.QMGR
QMNAME(UAT.QMGR)                                      STATUS(Running)
QMNAME(VTR1.QMGR)                                     STATUS(Ended normally)
QMNAME(BPAY.QMGR)                                     STATUS(Running)
QMNAME(AUTO.QMGR)                                     STATUS(Running)
QMNAME(DT.QMGR)                                       STATUS(Running)
QMNAME(INF.QMGR)                                      STATUS(Running)
QMNAME(VT.QMGR)                                       STATUS(Running)


Additional info:
policy file created by audit2allow
[10:03:18] root@tst-mq-01
/etc/nagios/plugins.d# cat /tmp/nrpe.policy.te

module nrpe.policy 1.0;

require {
        type unconfined_t;
        type nagios_etc_t;
        type pam_var_run_t;
        type initrc_var_run_t;
        type nrpe_t;
        type var_t;
        type nrpe_etc_t;
        class unix_stream_socket connectto;
        class file { create execute getattr lock open read write };
        class sock_file write;
        class sem { associate getattr read unix_read unix_write write };
        class shm { associate getattr read unix_read unix_write write };
        class dir { add_name getattr read search write };
}

#============= nrpe_t ==============

#!!!! This avc is allowed in the current policy
allow nrpe_t initrc_var_run_t:file { lock open read };

#!!!! This avc is allowed in the current policy
allow nrpe_t nagios_etc_t:dir read;

#!!!! This avc is allowed in the current policy
allow nrpe_t nrpe_etc_t:dir { getattr search };
allow nrpe_t pam_var_run_t:dir { add_name write };
allow nrpe_t pam_var_run_t:file { create getattr lock open read write };

#!!!! This avc is allowed in the current policy
allow nrpe_t unconfined_t:sem { associate getattr read unix_read unix_write write };

#!!!! This avc is allowed in the current policy
allow nrpe_t unconfined_t:shm { associate getattr read unix_read unix_write write };

#!!!! This avc is allowed in the current policy
allow nrpe_t unconfined_t:unix_stream_socket connectto;

#!!!! This avc is allowed in the current policy
allow nrpe_t var_t:dir write;

#!!!! This avc is allowed in the current policy
allow nrpe_t var_t:file { execute getattr lock open read write };

#!!!! This avc is allowed in the current policy
allow nrpe_t var_t:sock_file write;

Comment 1 Stephen John Smoogen 2017-12-01 00:35:08 UTC
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

Comment 2 Nigel 2017-12-01 01:21:40 UTC
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

Comment 3 Nigel 2017-12-01 01:23:31 UTC
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

Comment 4 Stephen John Smoogen 2017-12-01 02:06:13 UTC
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.

Comment 5 Nigel 2017-12-01 02:14:46 UTC
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;

Comment 6 Stephen John Smoogen 2017-12-01 02:23:10 UTC
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.

Comment 7 Nigel 2017-12-01 02:31:27 UTC
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

Comment 8 Stephen John Smoogen 2017-12-01 02:41:38 UTC
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.

Comment 9 Nigel 2017-12-01 02:43:47 UTC
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.

Comment 10 R P Herrold 2017-12-01 18:25:29 UTC
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

Comment 11 Nigel 2017-12-03 21:33:34 UTC
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

Comment 12 Fedora End Of Life 2018-02-20 15:24:30 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

Comment 13 Stephen John Smoogen 2018-07-24 20:49:38 UTC
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.


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