The following was filed automatically by setroubleshoot: Summary: Your system may be seriously compromised! /bin/dbus-daemon attempted to mmap low kernel memory. Detailed Description: [dbus-daemon has a permissive type (system_dbusd_t). This access was not denied.] SELinux has denied the dbus-daemon the ability to mmap low area of the kernel address space. The ability to mmap a low area of the address space, as configured by /proc/sys/kernel/mmap_min_addr. Preventing such mappings helps protect against exploiting null deref bugs in the kernel. All applications that need this access should have already had policy written for them. If a compromised application tries modify the kernel this AVC would be generated. This is a serious issue. Your system may very well be compromised. Allowing Access: Contact your security administrator and report this issue. Additional Information: Source Context system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 Target Context system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 Target Objects None [ memprotect ] Source dbus-daemon Source Path /bin/dbus-daemon Port <Unknown> Host (removed) Source RPM Packages dbus-1.2.16-5.fc12 Target RPM Packages Policy RPM selinux-policy-3.6.32-8.fc12 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name mmap_zero Host Name (removed) Platform Linux (removed) 2.6.31-33.fc12.x86_64 #1 SMP Thu Sep 17 15:40:43 EDT 2009 x86_64 x86_64 Alert Count 6 First Seen Thu 24 Sep 2009 05:51:15 PM GMT Last Seen Thu 24 Sep 2009 05:51:15 PM GMT Local ID 75d7dca8-4a1a-4aea-bb27-9c12bf5e3729 Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1253814675.340:13): avc: denied { mmap_zero } for pid=952 comm="dbus-daemon" scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tclass=memprotect node=(removed) type=AVC msg=audit(1253814675.340:13): avc: denied { mmap_zero } for pid=952 comm="dbus-daemon" scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tclass=memprotect node=(removed) type=AVC msg=audit(1253814675.340:13): avc: denied { mmap_zero } for pid=952 comm="dbus-daemon" scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tclass=memprotect node=(removed) type=SYSCALL msg=audit(1253814675.340:13): arch=c000003e syscall=125 success=yes exit=0 a0=7fff6d94af64 a1=0 a2=7fff6b677e80 a3=7fff3a622e30 items=0 ppid=1 pid=952 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="dbus-daemon" exe="/bin/dbus-daemon" subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 key=(null) flokipaudit2allow suggests: #============= system_dbusd_t ============== allow system_dbusd_t self:memprotect mmap_zero;
Dbus should not require this access.
I have no idea how the capget syscall keeps hitting mmap_zero. But this looks to be a kernel bug to me...
Is this reproducible?
I do not know. Sealet is not running, bug 525757.
*** Bug 526333 has been marked as a duplicate of this bug. ***
*** Bug 526531 has been marked as a duplicate of this bug. ***
*** Bug 527040 has been marked as a duplicate of this bug. ***
Finally got a reproducer, there must be both a userspace a kernel space bug involved here. Going to take a bit more digging tomorrow.
libcap/cap_alloc.c::cap_init() result->head.version = _LIBCAP_CAPABILITY_VERSION; capget(&result->head, NULL); /* load the kernel-capability version */ The problem with this is that the kernel only sets the .version when the version passed in is not valid. This call is actually trying to write a version 3 set of the capabilities to address 0. From the man page: The calls will fail with the error EINVAL, and set the version field of hdrp to the kernel preferred value of _LINUX_CAPABILITY_VERSION_? when an unsupported version value is specified. In this way, one can probe what the current preferred capability revision is. The best thing to do here is to either set .version = 0 before this call or to just 0 the entire struct before you make the call. This will fix the issue we are having with SELinux as well.
*** Bug 517582 has been marked as a duplicate of this bug. ***
*** Bug 528603 has been marked as a duplicate of this bug. ***
*** Bug 521075 has been marked as a duplicate of this bug. ***
*** Bug 529803 has been marked as a duplicate of this bug. ***
*** Bug 527472 has been marked as a duplicate of this bug. ***
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
*** Bug 539451 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.