A machine I set up to run OpenNMS stopped working last night - no hardware alarm lights, but keyboard/monitor/network unresponsive. After a reboot I see a large stack of messages like this in /var/log/messages:
---- Aug 20 14:02:34 opennms-h-03 python: SELinux is preventing /usr/sbin/monitor-get-edid-using-vbe from mmap _zero access on the memprotect .
***** Plugin mmap_zero (53.1 confidence) suggests *************************
If you do not think /usr/sbin/monitor-get-edid-using-vbe should need to mmap low memory in the kernel. Then you may be under attack by a hacker, this is a very dangerous access. Do contact your security administrator and report this issue.
***** Plugin catchall_boolean (42.6 confidence) suggests ******************
If you want to allow mmap to low allowed Then you must tell SELinux about this by enabling the 'mmap_low_allowed' boolean. You can read 'None' man page for more details. Do setsebool -P mmap_low_allowed 1
***** Plugin catchall (5.76 confidence) suggests **************************
If you believe that monitor-get-edid-using-vbe should be allowed mmap_zero access on the memprotect by d efault. 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 monitor-get-edi /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp
------ and then this final message
Aug 20 14:02:42 opennms-h-03 dbus-daemon: 'list' object has no attribute 'split'
Do either of those look fatal? And where else should I look for the underlying problem?
Les Mikesell wrote:
A machine I set up to run OpenNMS stopped working last night - no hardware alarm lights, but keyboard/monitor/network unresponsive. After a reboot I see a large stack of messages like this in /var/log/messages:
Aug 20 14:02:34 opennms-h-03 python: SELinux is preventing /usr/sbin/monitor-get-edid-using-vbe from mmap _zero access on the memprotect .
***** Plugin mmap_zero (53.1 confidence) suggests
If you do not think /usr/sbin/monitor-get-edid-using-vbe should need to mmap low memory in the kernel. Then you may be under attack by a hacker, this is a very dangerous access. Do contact your security administrator and report this issue.
***** Plugin catchall_boolean (42.6 confidence) suggests
If you want to allow mmap to low allowed Then you must tell SELinux about this by enabling the 'mmap_low_allowed' boolean. You can read 'None' man page for more details. Do setsebool -P mmap_low_allowed 1
***** Plugin catchall (5.76 confidence) suggests
If you believe that monitor-get-edid-using-vbe should be allowed mmap_zero access on the memprotect by d efault. 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 monitor-get-edi /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp
and then this final message
Aug 20 14:02:42 opennms-h-03 dbus-daemon: 'list' object has no attribute 'split'
Do either of those look fatal? And where else should I look for the underlying problem?
Looks like all selinux to me, esp. the wording. Is it in enforcing mode? I wonder if it's possible that there's a bug in an selinux policy that results in "IT'S NOT SAFE!!! SHUT IT DOWN!!!".
mark
On Thu, Aug 21, 2014 at 12:23 PM, m.roth@5-cent.us wrote:
Les Mikesell wrote:
A machine I set up to run OpenNMS stopped working last night - no hardware alarm lights, but keyboard/monitor/network unresponsive. After a reboot I see a large stack of messages like this in /var/log/messages:
Aug 20 14:02:34 opennms-h-03 python: SELinux is preventing /usr/sbin/monitor-get-edid-using-vbe from mmap _zero access on the memprotect .
and then this final message
Aug 20 14:02:42 opennms-h-03 dbus-daemon: 'list' object has no attribute 'split'
Do either of those look fatal? And where else should I look for the underlying problem?
Looks like all selinux to me, esp. the wording. Is it in enforcing mode? I wonder if it's possible that there's a bug in an selinux policy that results in "IT'S NOT SAFE!!! SHUT IT DOWN!!!".
/var/log/audit/audit.log says: type=AVC msg=audit(1408478520.792:7016): avc: denied { mmap_zero } for pid=17977 comm="monitor-get-edi" scontext=system_u:system_r:system_cronjob_t:s0-s0:c0.c1023 tcontext=system_u:system_r:system_cronjob_t:s0-s0:c0.c1023 tclass=memprotect
which isn't particularly readable but I would guess means that it blocked the ocsinventory-agent from getting the monitor type. Not sure why that is supposed to be helpful, but it also doesn't sound fatal. And somewhat irrelevant on a normally headless server.
Does that dbus error looks serious? Aug 20 14:02:42 opennms-h-03 dbus-daemon: 'list' object has no attribute 'split'
-- Les Mikesell lesmikesell@gmail.com
On 08/21/2014 02:09 PM, Les Mikesell wrote:
On Thu, Aug 21, 2014 at 12:23 PM, m.roth@5-cent.us wrote:
Les Mikesell wrote:
A machine I set up to run OpenNMS stopped working last night - no hardware alarm lights, but keyboard/monitor/network unresponsive. After a reboot I see a large stack of messages like this in /var/log/messages:
Aug 20 14:02:34 opennms-h-03 python: SELinux is preventing /usr/sbin/monitor-get-edid-using-vbe from mmap _zero access on the memprotect .
and then this final message
Aug 20 14:02:42 opennms-h-03 dbus-daemon: 'list' object has no attribute 'split'
Do either of those look fatal? And where else should I look for the underlying problem?
Looks like all selinux to me, esp. the wording. Is it in enforcing mode? I wonder if it's possible that there's a bug in an selinux policy that results in "IT'S NOT SAFE!!! SHUT IT DOWN!!!".
/var/log/audit/audit.log says: type=AVC msg=audit(1408478520.792:7016): avc: denied { mmap_zero } for pid=17977 comm="monitor-get-edi" scontext=system_u:system_r:system_cronjob_t:s0-s0:c0.c1023 tcontext=system_u:system_r:system_cronjob_t:s0-s0:c0.c1023 tclass=memprotect
which isn't particularly readable but I would guess means that it blocked the ocsinventory-agent from getting the monitor type. Not sure why that is supposed to be helpful, but it also doesn't sound fatal. And somewhat irrelevant on a normally headless server.
Does that dbus error looks serious? Aug 20 14:02:42 opennms-h-03 dbus-daemon: 'list' object has no attribute 'split'
-- Les Mikesell lesmikesell@gmail.com _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
mmap_zero is a fairly dangerous access. It means the object is attempting to memeory map low memory in the kernel. Bugs in the kernel have been known to allow priv escallation, can be prevented by this check.
http://eparis.livejournal.com/
Talks about the access check.
I usually tell people to avoid these apps, but if you need to run it, you can turn the protection off as the alert told you.
setsebool -P mmap_low_allowed 1
On Thu, Aug 21, 2014 at 4:07 PM, Daniel J Walsh dwalsh@redhat.com wrote:
mmap_zero is a fairly dangerous access. It means the object is attempting to memeory map low memory in the kernel. Bugs in the kernel have been known to allow priv escallation, can be prevented by this check.
http://eparis.livejournal.com/
Talks about the access check.
I usually tell people to avoid these apps, but if you need to run it,
Ocsinventory-agent wants to report the hardware where it runs back to the central server, including the attached monitor, if any. I think that is the source of the access. Is there a better way to do that in a perl script?
you can turn the protection off as the alert told you.
setsebool -P mmap_low_allowed 1
Thanks. This is a package from EPEL. Can they do something in the package to make it work without being blocked?
In any case, my real question is whether this could be related to the system hang. I don't really see why a failing access in a perl script would be a real problem unless there is some more serious bug, so it may not be related at all. There were several such log messages, so at least we know the first few weren't fatal.
-
Daniel J Walsh -
Les Mikesell -
m.roth＠5-cent.us