1201054 – [SELinux] [Nagios] SELinux blocks Nagios/NRPE plugins which use sudo - RHEL-7.2

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 1201054 - [SELinux] [Nagios] SELinux blocks Nagios/NRPE plugins which use sudo - RHEL-7.2

Summary: [SELinux] [Nagios] SELinux blocks Nagios/NRPE plugins which use sudo - RHEL-7.2

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	selinux-policy
Sub Component:
Version:	7.1
Hardware:	All
OS:	Linux
Priority:	high
Severity:	medium
Target Milestone:	rc
Target Release:	---
Assignee:	Miroslav Grepl
QA Contact:	Milos Malik
Docs Contact:
URL:
Whiteboard:
Duplicates (1):	1230670 (view as bug list)
Depends On:
Blocks:	1169221 1212796 1230299
TreeView+	depends on / blocked

Reported:	2015-03-11 23:46 UTC by James Ralston
Modified:	2015-11-19 10:28 UTC (History)
CC List:	11 users (show)
Fixed In Version:	selinux-policy-3.13.1-26.el7
Doc Type:	Bug Fix
Doc Text:
Clone Of:
Clones:	1230299 (view as bug list)
Environment:
Last Closed:	2015-11-19 10:28:44 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHBA-2015:2300	0	normal	SHIPPED_LIVE	selinux-policy bug fix update	2015-11-19 09:55:26 UTC

Description James Ralston 2015-03-11 23:46:51 UTC

Description of problem:

Some Nagios plugins, when run remotely via nrpe, need to be run with sudo in order function properly. But SELinux policy is preventing sudo from executing.

Version-Release number of selected component (if applicable):

selinux-policy-targeted-3.13.1-23.el7.noarch

How reproducible:

Call a Nagios plugin remotely via sudo. E.g., use this nrpe definition:

command[check_disk]=sudo /usr/lib64/nagios/plugins/check_disk $ARG1$

$ ls -Z /usr/lib64/nagios/plugins/check_disk 
-rwxr-xr-x. root root system_u:object_r:nagios_checkdisk_plugin_exec_t:s0 /usr/lib64/nagios/plugins/check_disk*

Despite the check_disk plugin having the correct file context, if SELinux is in enforcing mode, when NRPE calls the plugin remotely, it will fail:

$ check_nrpe -H host.example.org -p 5666 -c check_disk -a "-e -E -w 10% -c 5% -p /"
NRPE: Unable to read output

But if SELinux is in non-enforcing mode, the plugin will succeed:

$ check_nrpe -H host.example.org -p 5666 -c check_disk -a "-e -E -w 10% -c 5% -p /"
DISK OK| /=1712MB;14398;15198;0;15998

Additional info:

We had this exact same problem with RHEL6 (bug 917157), although the underlying causes appear to be different in this case.

The denial that is causing the problem is being hidden with dontaudit, so I had to disable dontaudit temporarily to get at it. Here are all of the denials that are being hidden by dontaudit (in non-enforcing mode):

----
time->Wed Mar 11 19:35:01 2015
type=SYSCALL msg=audit(1426116901.940:13713): arch=c000003e syscall=41 success=yes exit=7 a0=10 a1=3 a2=9 a3=7fff45594cb0 items=0 ppid=3435 pid=3436 auid=4294967295 uid=994 gid=993 euid=0 suid=0 fsuid=0 egid=993 sgid=993 fsgid=993 tty=(none) ses=4294967295 comm="sudo" exe="/usr/bin/sudo" subj=system_u:system_r:nrpe_t:s0 key=(null)
type=AVC msg=audit(1426116901.940:13713): avc:  denied  { create } for  pid=3436 comm="sudo" scontext=system_u:system_r:nrpe_t:s0 tcontext=system_u:system_r:nrpe_t:s0 tclass=netlink_audit_socket
----
time->Wed Mar 11 19:35:01 2015
type=SYSCALL msg=audit(1426116901.940:13714): arch=c000003e syscall=44 success=yes exit=272 a0=7 a1=7fff4558a490 a2=110 a3=0 items=0 ppid=3435 pid=3436 auid=4294967295 uid=994 gid=993 euid=0 suid=0 fsuid=0 egid=993 sgid=993 fsgid=993 tty=(none) ses=4294967295 comm="sudo" exe="/usr/bin/sudo" subj=system_u:system_r:nrpe_t:s0 key=(null)
type=AVC msg=audit(1426116901.940:13714): avc:  denied  { audit_write } for  pid=3436 comm="sudo" capability=29  scontext=system_u:system_r:nrpe_t:s0 tcontext=system_u:system_r:nrpe_t:s0 tclass=capability
type=AVC msg=audit(1426116901.940:13714): avc:  denied  { nlmsg_relay } for  pid=3436 comm="sudo" scontext=system_u:system_r:nrpe_t:s0 tcontext=system_u:system_r:nrpe_t:s0 tclass=netlink_audit_socket
type=AVC msg=audit(1426116901.940:13714): avc:  denied  { write } for  pid=3436 comm="sudo" scontext=system_u:system_r:nrpe_t:s0 tcontext=system_u:system_r:nrpe_t:s0 tclass=netlink_audit_socket
----
time->Wed Mar 11 19:35:01 2015
type=SYSCALL msg=audit(1426116901.940:13716): arch=c000003e syscall=45 success=yes exit=36 a0=7 a1=7fff4558c7c0 a2=231c a3=42 items=0 ppid=3435 pid=3436 auid=4294967295 uid=994 gid=993 euid=0 suid=0 fsuid=0 egid=993 sgid=993 fsgid=993 tty=(none) ses=4294967295 comm="sudo" exe="/usr/bin/sudo" subj=system_u:system_r:nrpe_t:s0 key=(null)
type=AVC msg=audit(1426116901.940:13716): avc:  denied  { read } for  pid=3436 comm="sudo" scontext=system_u:system_r:nrpe_t:s0 tcontext=system_u:system_r:nrpe_t:s0 tclass=netlink_audit_socket
----
time->Wed Mar 11 19:35:01 2015
type=SYSCALL msg=audit(1426116901.941:13719): arch=c000003e syscall=160 success=yes exit=0 a0=6 a1=7fff45594d40 a2=0 a3=40 items=0 ppid=3435 pid=3436 auid=4294967295 uid=0 gid=993 euid=0 suid=0 fsuid=0 egid=993 sgid=993 fsgid=993 tty=(none) ses=4294967295 comm="sudo" exe="/usr/bin/sudo" subj=system_u:system_r:nrpe_t:s0 key=(null)
type=AVC msg=audit(1426116901.941:13719): avc:  denied  { sys_resource } for  pid=3436 comm="sudo" capability=24  scontext=system_u:system_r:nrpe_t:s0 tcontext=system_u:system_r:nrpe_t:s0 tclass=capability
----
time->Wed Mar 11 19:35:01 2015
type=SYSCALL msg=audit(1426116901.941:13720): arch=c000003e syscall=59 success=yes exit=0 a0=7fd4cdce68f8 a1=7fd4cdcdeb28 a2=7fd4cdce6450 a3=9 items=0 ppid=3436 pid=3437 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="check_disk" exe="/usr/lib64/nagios/plugins/check_disk" subj=system_u:system_r:nagios_checkdisk_plugin_t:s0 key=(null)
type=AVC msg=audit(1426116901.941:13720): avc:  denied  { noatsecure } for  pid=3437 comm="check_disk" scontext=system_u:system_r:nrpe_t:s0 tcontext=system_u:system_r:nagios_checkdisk_plugin_t:s0 tclass=process
type=AVC msg=audit(1426116901.941:13720): avc:  denied  { siginh } for  pid=3437 comm="check_disk" scontext=system_u:system_r:nrpe_t:s0 tcontext=system_u:system_r:nagios_checkdisk_plugin_t:s0 tclass=process
type=AVC msg=audit(1426116901.941:13720): avc:  denied  { rlimitinh } for  pid=3437 comm="check_disk" scontext=system_u:system_r:nrpe_t:s0 tcontext=system_u:system_r:nagios_checkdisk_plugin_t:s0 tclass=process

In enforcing mode, only the first denial (the failure to create self:netlink_audit_socket) is logged, so that is the denial that kills sudo.

I don't know whether the successive denials would be fatal to sudo.

Comment 2 James Ralston 2015-03-18 19:49:46 UTC

We rolled the following custom SELinux module to address these issues:

    # Module name and version.
    policy_module(nagios-local, 1.1.0)

    # Type requires.
    require {
            type nrpe_t;
            type sudo_exec_t;
    }

    # Permit NRPE to call sudo.
    can_exec(nrpe_t, sudo_exec_t)

    # Permit NRPE to send audit messages, via sudo.
    allow nrpe_t self:capability { audit_write sys_ptrace };
    allow nrpe_t self:netlink_audit_socket { create nlmsg_relay read write };

(We use this same policy module on both RHEL6 and RHEL7, so it's a superset of the permissions required on both.)

It would be really nice if you could fix the upstream policy, though, so we didn't have to resort to this work-around.

Comment 3 Miroslav Grepl 2015-04-09 09:14:18 UTC

I would add a boolean for this.

Comment 4 Milos Malik 2015-04-20 09:49:46 UTC

I believe that following files should not be labeled bin_t:

/usr/lib64/nagios/plugins/negate
/usr/lib64/nagios/plugins/urlize
/usr/lib64/nagios/plugins/utils.sh

Comment 5 James Ralston 2015-04-29 03:30:08 UTC

In reply to Miroslav in comment 3: adding a boolean seems perfectly reasonable to me, as I can imagine that only a subset of Nagios/NRPE users need to call NRPE plugins via sudo.

Comment 7 Miroslav Grepl 2015-05-14 13:21:15 UTC

Any chance to test it with

https://brewweb.devel.redhat.com/buildinfo?buildID=435085

Comment 8 Miroslav Grepl 2015-05-19 10:04:10 UTC

We have some fixes but I am working on additional fixes now.

Comment 12 Simon Sekidde 2015-06-13 22:48:43 UTC

*** Bug 1230670 has been marked as a duplicate of this bug. ***

Comment 13 Stanislav Graf 2015-06-24 19:25:39 UTC

I've retested today with
selinux-policy-targeted-3.13.1-29.el7.noarch

All works as expected. I saw one new nrpe related issue on one of RHEL6 nodes, created Bug 1235405.

I had following booleans status on nagios server node:
nagios_run_pnp4nagios --> on
nagios_run_sudo --> on

and following on monitored node:
nagios_run_pnp4nagios --> off
nagios_run_sudo --> on

Comment 16 errata-xmlrpc 2015-11-19 10:28:44 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-2300.html

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