Bug 1268948 - SELinux is preventing /usr/bin/perl from using the 'execmem' accesses on a process.
SELinux is preventing /usr/bin/perl from using the 'execmem' accesses on a pr...
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: munin (Show other bugs)
23
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: d. johnson
Fedora Extras Quality Assurance
abrt_hash:90e45505d9f98eec17de9fb90bf...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-05 13:32 EDT by zimon
Modified: 2015-10-16 12:46 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-10-16 12:46:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description zimon 2015-10-05 13:32:11 EDT
Description of problem:
SELinux is preventing /usr/bin/perl from using the 'execmem' accesses on a process.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that perl should be allowed execmem access on processes labeled munin_t by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep munin-update /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:munin_t:s0-s0:c0.c1023
Target Context                system_u:system_r:munin_t:s0-s0:c0.c1023
Target Objects                Unknown [ process ]
Source                        munin-update
Source Path                   /usr/bin/perl
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           perl-5.18.4-309.fc21.x86_64
                              perl-5.20.3-327.fc22.x86_64
                              perl-5.22.0-349.fc23.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.13.1-147.fc23.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 4.2.2-300.fc23.x86_64 #1 SMP Wed
                              Sep 30 01:36:26 UTC 2015 x86_64 x86_64
Alert Count                   3346
First Seen                    2015-09-23 21:45:02 EEST
Last Seen                     2015-10-05 20:25:02 EEST
Local ID                      a96db411-d8c9-4cb6-8047-277d7c3a2924

Raw Audit Messages
type=AVC msg=audit(1444065902.229:25801): avc:  denied  { execmem } for  pid=26959 comm="munin-update" scontext=system_u:system_r:munin_t:s0-s0:c0.c1023 tcontext=system_u:system_r:munin_t:s0-s0:c0.c1023 tclass=process permissive=0


type=SYSCALL msg=audit(1444065902.229:25801): arch=x86_64 syscall=mprotect success=no exit=EACCES a0=7efc502fc000 a1=33000 a2=7 a3=484 items=0 ppid=26957 pid=26959 auid=478 uid=478 gid=465 euid=478 suid=478 fsuid=478 egid=465 sgid=465 fsgid=465 tty=(none) ses=679 comm=munin-update exe=/usr/bin/perl subj=system_u:system_r:munin_t:s0-s0:c0.c1023 key=(null)

Hash: munin-update,munin_t,munin_t,process,execmem

Version-Release number of selected component:
selinux-policy-3.13.1-147.fc23.noarch

Additional info:
reporter:       libreport-2.6.2
hashmarkername: setroubleshoot
kernel:         4.2.2-300.fc23.x86_64
type:           libreport

Potential duplicate: bug 913294
Comment 1 zimon 2015-10-13 14:21:25 EDT
This has been reported also with F21 and F22 in a bug 1266106.

Those SELinux exception reports started when I installed munin to the system. 

Currently versions of munin packages are:
# rpm -qa|grep munin
munin-node-2.0.25-4.fc23.noarch
munin-common-2.0.25-4.fc23.noarch
munin-2.0.25-4.fc23.noarch
Comment 2 zimon 2015-10-15 15:51:56 EDT
Found something, which  has something to do with those AVCs.
The time stamps match.
If complains about /usr/bin/nvclock

**** From ausearch -m avc -i | tail

type=PROCTITLE msg=audit(10/15/2015 21:39:02.915:59047) : proctitle=/usr/bin/perl -wT /usr/sbin/munin-node 

type=SYSCALL msg=audit(10/15/2015 21:39:02.915:59047) : arch=x86_64 syscall=stat success=yes exit=0 a0=0x1d1c1e0 a1=0x1b34298 a2=0x1b34298 a3=0x0 items=0 ppid=1 pid=18961 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=munin-node exe=/usr/bin/perl subj=system_u:system_r:munin_t:s0 key=(null) 

type=AVC msg=audit(10/15/2015 21:39:02.915:59047) : avc:  denied  { net_admin } for  pid=18961 comm=munin-node capability=net_admin  scontext=system_u:system_r:munin_t:s0 tcontext=system_u:system_r:munin_t:s0 tclass=capability permissive=0

**** From /var/log/munin-node/munin-node.log:

2015/10/15-21:39:02 Munin::Node::Server (type Net::Server::Fork) starting! pid(1
8961)
Resolved [*]:4949 to [::]:4949, IPv6
Not including resolved host [0.0.0.0] IPv4 because it will be handled by [::] IP
v6
Binding open file descriptors
Binding to TCP port 4949 on host :: with IPv6
Reassociating file descriptor 6 with TCP on [::]:4949, using IPv6
Setting gid to "0 0"
2015/10/15-21:39:03 [18961] Error output from nvidia_temp:
2015/10/15-21:39:03 [18961]     Could not close command /usr/bin/nvclock: 
2015/10/15-21:39:03 [18961] Service 'nvidia_temp' exited with status 255/0.
2015/10/15-21:39:03 [18961] Error output from nvidia_volt:
2015/10/15-21:39:03 [18961]     Could not close command /usr/bin/nvclock: 
2015/10/15-21:39:03 [18961] Service 'nvidia_volt' exited with status 255/0.
2015/10/15-21:39:03 [18961] Error output from nvidia_clock:
2015/10/15-21:39:03 [18961]     Could not close command /usr/bin/nvclock: 
2015/10/15-21:39:03 [18961] Service 'nvidia_clock' exited with status 255/0.
2015/10/15-21:39:23 Server closing!
Process Backgrounded
Comment 3 d. johnson 2015-10-15 20:27:08 EDT
You have the nvidia.com (negativo / rpmfusion) driver installed?

It looks like the plugin calls nvclock which needs execmem.
Comment 4 zimon 2015-10-16 03:37:56 EDT

Yes I have nvidia proprietary driver in use.
The driver has been compiled in house, with akmods
The src.rpm is from Rpmfusion.

Some research:

# uname -r
4.2.3-300.fc23.x86_64

# lsmod|grep nvidia
nvidia               8663040  87
drm                   335872  6 nvidia

# modinfo nvidia | grep filename
filename:       /lib/modules/4.2.3-300.fc23.x86_64/extra/nvidia/nvidia.ko

# rpm -qif /lib/modules/4.2.3-300.fc23.x86_64/extra/nvidia/nvidia.ko | grep -E 'Name|Source'
Name        : kmod-nvidia-4.2.3-300.fc23.x86_64
Source RPM  : nvidia-kmod-355.11-3.fc23.src.rpm

# nvclock -i
It seems your card isn't officialy supported in NVClock yet.
The reason can be that your card is too new.
If you want to try it anyhow [DANGEROUS], use the option -f to force the setting(s).
NVClock will then assume your card is a 'normal', it might be dangerous on other cards.
Also please email the author the pci_id of the card for further investigation.
[Get that value using the -i option].

# nvclock -s
Card:           Unknown Nvidia card
Card number:    1
Memory clock:   -2147483.750 MHz
GPU clock:      -2147483.750 MHz

# nvclock -T
It seems your card isn't officialy supported in NVClock yet.
The reason can be that your card is too new.
If you want to try it anyhow [DANGEROUS], use the option -f to force the setting(s).
NVClock will then assume your card is a 'normal', it might be dangerous on other cards.
Also please email the author the pci_id of the card for further investigation.
[Get that value using the -i option].

# lspci|grep -i nvidia
01:00.0 VGA compatible controller: NVIDIA Corporation GF110 [GeForce GTX 570] (rev a1)
01:00.1 Audio device: NVIDIA Corporation GF110 High Definition Audio Controller (rev a1)

# nvclock -i -f
-- General info --
Card:           Unknown Nvidia card
Architecture:   GC8 A1
PCI id:         0x0
GPU clock:      -2147483.750 MHz
Bustype:        PCI

-- Memory info --
Amount:         0 MB
Type:           128 bit SDR
Clock:          -2147483.750 MHz

# nvclock -T -f
Error: temperature monitoring isn't supported on your videocard.
Comment 5 zimon 2015-10-16 08:05:49 EDT
http://munin-monitoring.org/browser/munin-dev/plugins/node.d/nvidia_.in

There nvclock is used, if it is found in a system where munin is run.

I noticed, nvclock is rather old, at least on my system, from Fedora 20:

$ rpm -qif `which nvclock`
Name        : nvclock
Version     : 0.8
Release     : 0.17.b4.fc20
Architecture: x86_64
Install Date: Sat 04 Jan 2014 11:27:28 AM EET
Group       : Applications/System
Size        : 287451
License     : GPLv2+ and MIT
Signature   : RSA/SHA256, Wed 07 Aug 2013 08:18:35 AM EEST, Key ID 2eb161fa246110c1
Source RPM  : nvclock-0.8-0.17.b4.fc20.src.rpm
Build Date  : Sat 03 Aug 2013 08:18:37 PM EEST
Build Host  : buildvm-24.phx2.fedoraproject.org

In http://sourceforge.net/projects/nvclock/
last update is in year 2013. Maybe obsoleted.

Now nvidia-settings would provide same kind of information, 
http://http.download.nvidia.com/XFree86/Linux-x86/1.0-8756/README/appendix-t.html

eg.:

$ nvidia-settings  --query=GPUCoreTemp | head -2 | tail -1
  Attribute 'GPUCoreTemp' (myfedorahost:1.0): 53.

$ nvidia-settings  --query=GPUCurrentClockFreqsString |head -2|tail -1
  Attribute 'GPUCurrentClockFreqsString' (myfedorahost:1.0): nvclock=50,

$ rpm -qf `which nvidia-settings`
xorg-x11-drv-nvidia-355.11-1.fc21.x86_64

So, I guess upstream (munin github team) has to be notified.
Comment 6 d. johnson 2015-10-16 09:51:15 EDT
Unfortunately, this:

Name        : kmod-nvidia-4.2.3-300.fc23.x86_64

is not supported by fedora.  it is known to cause several selinux policy issues for starters.
Comment 7 Miroslav Grepl 2015-10-16 11:25:38 EDT
Could you collect all AVCs for your issue and we can create a local policy to make it working?
Comment 8 zimon 2015-10-16 12:46:36 EDT
So basically I would just do:

# grep munin /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

...to get rid of those? I've sometimes done those to get rid of AVCs.

But as nvclock doesn't work anyway for my "newish" nVidia hardware, if I just remove nvclock package, munin won't get bothered about it anymore. 
Or I could just "rm /etc/munin/plugins/nvidia_*"

And thirdly, I am thinking of switching from nVidia to nouveau kernel driver. It is true nvidia causes many troubles, eg. currently Xorg v3.18 in Fedora 23 doesn't work with nvidia, but I had to downgrade to Xorg v3.17. I suspect also AVC's caused by motion program are because of nVidia proprietary driver, like maybe this bug 1192698.

As I wrote in another thread, should I worry there is some kind of trojan horse in the system. nVidia closed source proprietary driver kind of IS a trojan horse already, needing all kind of special privileges which seem not to be related to what was tried to do with some other program.
I do not much play 3D-games anymore and I haven't been experimented with CUDA either lately, so switching to nouveau driver could be the right move for me after all.

So, if in upstream, munin developers would want to improve it, they would switch from obsoleted nvclock to nvidia-settings in nvidia_* munin-plugins.

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