The following was filed automatically by setroubleshoot: Summary: SELinux is preventing /usr/sbin/vbetool "mmap_zero" access on <Unknown>. Detailed Description: SELinux denied access requested by vbetool. The current boolean settings do not allow this access. If you have not setup vbetool to require this access this may signal an intrusion attempt. If you do intend this access you need to change the booleans on this system to allow the access. Allowing Access: Confined processes can be configured to run requiring different access, SELinux provides booleans to allow you to turn on/off access as needed. The boolean mmap_low_allowed is set incorrectly. Boolean Description: Allow certain domains to map low memory in the kernel Fix Command: # setsebool -P mmap_low_allowed 1 Additional Information: Source Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1 023 Target Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1 023 Target Objects None [ memprotect ] Source vbetool Source Path /usr/sbin/vbetool Port <Unknown> Host (removed) Source RPM Packages vbetool-1.2.2-1.fc12 Target RPM Packages Policy RPM selinux-policy-3.6.32-12.fc12 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_boolean Host Name (removed) Platform Linux (removed) 2.6.31.1-58.local.fc12.i686.PAE #1 SMP Sun Oct 4 14:18:52 CEST 2009 i686 i686 Alert Count 1 First Seen on. 07. okt. 2009 kl. 21.15 +0000 Last Seen on. 07. okt. 2009 kl. 21.15 +0000 Local ID 25f17148-38ff-4b13-ada1-46b5789c76e6 Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1254942950.241:52): avc: denied { mmap_zero } for pid=3939 comm="vbetool" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=memprotect node=(removed) type=SYSCALL msg=audit(1254942950.241:52): arch=40000003 syscall=192 success=no exit=-13 a0=1000 a1=a0000 a2=7 a3=11 items=0 ppid=3744 pid=3939 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty2 ses=4 comm="vbetool" exe="/usr/sbin/vbetool" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) Hash String generated from selinux-policy-3.6.32-12.fc12,catchall_boolean,vbetool,unconfined_t,unconfined_t,memprotect,mmap_zero audit2allow suggests: #============= unconfined_t ============== allow unconfined_t self:memprotect mmap_zero;
Is your machine suspend/resume working properly?
You can set this boolean # setsebool -P mmap_low_allowed 1 To eliminate the error message.
Did you run vbetool directly?
Suspend/resume is not working and yes I just ran vbetool with no arguments.
Could you turn the boolean on and see if suspend/resume works.
I ran the command as root and tried suspend/resume after it had completed but it still failed in the same way. Keyboard working, but display remains black after resume.
An no AVC? I guess put the machine in permissive mode and try again. If it fails to Resume, you have to blame it on someone else :^)
selinux=0 makes suspend/resume work again I'm sorry to say :-)
*** Bug 526757 has been marked as a duplicate of this bug. ***
Could you put the machine back in permissive mode. "enforcing=0", then get it to suspend/resume. See if it generates any AVC messages. You can also try #semodule -DB Which will remove all dontaudit rules. THen compress and attach the audit.log or email it to dwalsh
Created attachment 364438 [details] Audit log First suspend / resume cycle after relabeling the filesystem when booting into permissive mode didn't generate any AVC messages other than for authenticating. This is the log after running semodule -DB and doing another s/r cycle.
I had to run in permissive mode when relabeling to be able to finish the process and get the system up and running btw. When I ran in enforcing mode the relabeling process got stuck after apparently finishing but then getting stuck with init respawning over and over. Looks like it couldn't delete /.autorelabel and thus started the whole thing over again on next boot.
I don't see any AVC's related to suspend/resume. Or anything else that would matter. Did the machine suspend/resume fine in permissive mode?
yes, it works fine in permissive and enforcing mode now. Maybe something to do with relabeling or semodule -DB?
Maybe, but the question about the proper setting of mmap_zero boolean is really what is needed. If you turn it off again. # setsebool -P mmap_low_allowed 0 Does suspend/resume continue to work?
Looks like it yes.
*** Bug 522380 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
I started collecting messages like that one type=1400 audit(1259338949.762:3): avc: denied { mmap_zero } for pid=459 comm="vbetool" scontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tcontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tclass=memprotect after an update of an x86_64 machine to Fedora 12. selinux-policy-3.6.32-46.fc12.noarch selinux-policy-targeted-3.6.32-46.fc12 There is no question of suspending that particular box and I am not sure why even vbetool is called (this happens to a be a small server without X) but a message like the one above shows up on every boot. I do not think that in this particular case this makes any difference in operation except of a noise in /var/log/messages.
Apr 21 09:06:53 localhost kernel: type=1400 audit(1271840807.044:4): avc: denied { mmap_zero } for pid=549 comm="vbetool" scontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tcontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tclass=memprotect selinux-policy-3.6.32-110.fc12.noarch
I'd like to post an interesting data point of the opposite problem. My system's suspend/resume isn't working 100%, sometimes it hangs, but works most of the time. In an attempt to increase quality, I set # setsebool -P mmap_low_allowed 1 but that only made things worse and while the machine would suspend and resume, it couldn't switch the screen on anymore. I could issue commands, as long as I knew what I was doing, e.g. log in to a console and type reboot, for example. But the screen wouldn't come back. Having reverted # setsebool -P mmap_low_allowed 0 Things are OK now. Some more data: # rpm -q kernel selinux-policy selinux-policy-targeted vbetool kernel-2.6.33.5-124.fc13.x86_64 kernel-2.6.33.6-147.fc13.x86_64 kernel-2.6.33.6-147.2.4.fc13.x86_64 selinux-policy-3.7.19-39.fc13.noarch selinux-policy-targeted-3.7.19-39.fc13.noarch vbetool-1.2.2-1.fc12.x86_64 # dmidecode <SNIP> Handle 0x0002, DMI type 2, 15 bytes Base Board Information Manufacturer: ASUSTeK Computer INC. Product Name: M4A88T-M <SNIP> Handle 0x0004, DMI type 4, 40 bytes Processor Information Socket Designation: AM3 <SNIP> # I hope this extra data helps the team.
I submitted a separate bug report for my bug, here: https://bugzilla.redhat.com/show_bug.cgi?id=622737
*** Bug 636586 has been marked as a duplicate of this bug. ***
Looks like /etc/udev/rules.d/92-video-post.rules will run vbetool at boot: ACTION=="add", SUBSYSTEM=="pci", ATTRS{class}=="0x030000", RUN+="/usr/sbin/vbetool udevpost %k" So are we really stuck with these messages at boot?
You can set vbetool_mmap_zero_ignore boolean on for F14, maybe for f12 and f13
No go for f13 at the moment.
(In reply to comment #24) > Looks like /etc/udev/rules.d/92-video-post.rules will run vbetool at boot: ... > So are we really stuck with these messages at boot? Presumably these rules are there for a reason. I would think that in such case messages are a minor problem but a banned action a bigger one. If this is truly not the case then dropping that offending rule would kill complaints as well.
Changing to version 14 and proposing as a blocker under the criteria: "In most cases, there must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login" -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Miroslav, can you add the rules for ignore_mmap_zero to f13/RHEL6. getsebool -a | grep vbetool vbetool_mmap_zero_ignore --> off
Added to selinux-policy-3.7.19-62.fc13
selinux-policy-3.7.19-62.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/selinux-policy-3.7.19-62.fc13
selinux-policy-3.7.19-62.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update selinux-policy'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/selinux-policy-3.7.19-62.fc13
So from an F14 blocker perspective, the problem here, as I understand it, is that what vbetool does really *is* bad and we really *don't* want to make selinux not complain about it. So the ideal fix is to make vbetool not do the bad thing. Dan (and ajax), is that possible at all? Can vbetool be adjusted to not trip up selinux? If not, we'll have to except this issue from the release criteria, I believe, as we definitely want to have the alert when vbetool does this.
jesse points out that if we're going to leave the selinux alert in, we should get the opinion of desktop/ux people as to how it's presented and worded.
selinux-policy-3.7.19-62.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
Re-opening for F14 issue tracking, and because this update doesn't really fix the alert exactly, it simply provides F13 with the option to disable it.
This was discussed at the 2010-10-08 blocker review meeting. We agreed to accept this as a blocker and endorse ajax's recommendation to deal with it by not installing vbetool by default. This may affect suspend on systems which don't use a KMS video driver (that's very few systems now). We will add a release note or common bug to document that users of such systems can install vbetool manually if they have problems suspending.
pm-utils-1.3.1-2.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/pm-utils-1.3.1-2.fc14
pm-utils-1.3.1-2.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update pm-utils'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/pm-utils-1.3.1-2.fc14
There is time to get content in for the 0-day update to Release Notes. However, it's helpful to: * set the appropriate BZ flag (done) * provide some text for the Docs team so they don't have to read and grok the whole bug to accomplish the goal of including a release note I've added a suggestion for the release note in the Technical Notes field above. Dan, AdamW, ajax -- please review and edit it if needed.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: The vbetool utility is no longer installed by default in Fedora 14. It is not required by the majority of systems now, which are covered by Fedora's kernel mode setting (KMS) video drivers, and may cause an SELinux alert when launched. However, on a small number of systems the omission of vbetool may cause problems with suspend and resume functions. If you experience problems with suspend and resume and your system does not use a KMS driver, you may wish to install the vbetool package, and tune SELinux to avoid the resulting alert. Use the following commands: su -c 'yum install vbetool' su -c 'setsebool -P vbetool_mmap_zero_ignore 1'
pm-utils-1.3.1-2.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 647327 has been marked as a duplicate of this bug. ***