Bug 528022 - setroubleshoot: SELinux is preventing /usr/sbin/vbetool "mmap_zero" access on <Unknown>.
setroubleshoot: SELinux is preventing /usr/sbin/vbetool "mmap_zero" acce...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: vbetool (Show other bugs)
14
All Linux
low Severity medium
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
setroubleshoot_trace_hash:8c7dfe3f44a...
: Reopened, SELinux, Triaged
: 522380 526757 636586 647327 (view as bug list)
Depends On:
Blocks: F14Blocker/F14FinalBlocker 641421
  Show dependency treegraph
 
Reported: 2009-10-08 12:20 EDT by Kjartan Maraas
Modified: 2010-10-28 08:32 EDT (History)
17 users (show)

See Also:
Fixed In Version: pm-utils-1.3.1-2.fc14
Doc Type: Bug Fix
Doc Text:
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'
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-10-13 08:46:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
stickster: fedora_requires_release_note+


Attachments (Terms of Use)
Audit log (181.91 KB, text/plain)
2009-10-12 03:34 EDT, Kjartan Maraas
no flags Details

  None (edit)
Description Kjartan Maraas 2009-10-08 12:20:01 EDT
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;
Comment 1 Daniel Walsh 2009-10-08 14:26:54 EDT
Is your machine suspend/resume working properly?
Comment 2 Daniel Walsh 2009-10-08 14:27:23 EDT
You can set this boolean

# setsebool -P mmap_low_allowed 1

To eliminate the error message.
Comment 3 Daniel Walsh 2009-10-08 14:35:40 EDT
Did you run vbetool directly?
Comment 4 Kjartan Maraas 2009-10-08 15:21:57 EDT
Suspend/resume is not working and yes I just ran vbetool with no arguments.
Comment 5 Daniel Walsh 2009-10-08 17:01:51 EDT
Could you turn the boolean on and see if suspend/resume works.
Comment 6 Kjartan Maraas 2009-10-09 02:12:26 EDT
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.
Comment 7 Daniel Walsh 2009-10-09 08:05:46 EDT
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 :^)
Comment 8 Kjartan Maraas 2009-10-10 07:49:43 EDT
selinux=0 makes suspend/resume work again I'm sorry to say :-)
Comment 9 Kjartan Maraas 2009-10-10 10:45:39 EDT
*** Bug 526757 has been marked as a duplicate of this bug. ***
Comment 10 Daniel Walsh 2009-10-11 07:51:38 EDT
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@redhat.com
Comment 11 Kjartan Maraas 2009-10-12 03:34:17 EDT
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.
Comment 12 Kjartan Maraas 2009-10-12 03:35:25 EDT
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.
Comment 13 Daniel Walsh 2009-10-13 17:03:04 EDT
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?
Comment 14 Kjartan Maraas 2009-10-13 18:31:28 EDT
yes, it works fine in permissive and enforcing mode now. Maybe something to do with relabeling or semodule -DB?
Comment 15 Daniel Walsh 2009-10-14 09:05:17 EDT
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?
Comment 16 Kjartan Maraas 2009-10-14 10:17:36 EDT
Looks like it yes.
Comment 17 Daniel Walsh 2009-10-20 17:34:07 EDT
*** Bug 522380 has been marked as a duplicate of this bug. ***
Comment 18 Bug Zapper 2009-11-16 08:25:29 EST
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
Comment 19 Michal Jaegermann 2009-11-27 13:14:50 EST
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.
Comment 20 Orion Poplawski 2010-04-21 13:08:23 EDT
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
Comment 21 A. Folger 2010-08-08 12:21:19 EDT
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.
Comment 22 A. Folger 2010-08-10 05:47:43 EDT
I submitted a separate bug report for my bug, here: https://bugzilla.redhat.com/show_bug.cgi?id=622737
Comment 23 Daniel Walsh 2010-09-22 16:07:43 EDT
*** Bug 636586 has been marked as a duplicate of this bug. ***
Comment 24 Orion Poplawski 2010-09-23 16:52:29 EDT
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?
Comment 25 Daniel Walsh 2010-09-23 17:18:00 EDT
You can set vbetool_mmap_zero_ignore boolean on for F14, maybe for f12 and f13
Comment 26 Orion Poplawski 2010-09-23 17:22:20 EDT
No go for f13 at the moment.
Comment 27 Michal Jaegermann 2010-09-23 18:32:24 EDT
(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.
Comment 28 Jeff Raber 2010-09-23 19:41:55 EDT
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
Comment 29 Daniel Walsh 2010-09-24 09:08:36 EDT
Miroslav, can you add the rules for ignore_mmap_zero to f13/RHEL6.

getsebool -a | grep vbetool
vbetool_mmap_zero_ignore --> off
Comment 30 Miroslav Grepl 2010-09-24 09:21:03 EDT
Added to selinux-policy-3.7.19-62.fc13
Comment 31 Fedora Update System 2010-09-24 09:58:29 EDT
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
Comment 32 Fedora Update System 2010-09-26 00:32:30 EDT
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
Comment 33 Adam Williamson 2010-10-01 16:26:24 EDT
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.
Comment 34 Adam Williamson 2010-10-01 16:26:57 EDT
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.
Comment 35 Fedora Update System 2010-10-05 05:35:21 EDT
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.
Comment 36 Adam Williamson 2010-10-05 14:34:11 EDT
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.
Comment 37 Adam Williamson 2010-10-08 12:48:13 EDT
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.
Comment 38 Fedora Update System 2010-10-08 12:58:32 EDT
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
Comment 39 Fedora Update System 2010-10-08 22:55:34 EDT
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
Comment 40 Paul W. Frields 2010-10-13 07:21:23 EDT
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.
Comment 41 Paul W. Frields 2010-10-13 07:21:24 EDT
    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'
Comment 42 Fedora Update System 2010-10-13 08:46:21 EDT
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.
Comment 43 Daniel Walsh 2010-10-28 08:32:42 EDT
*** Bug 647327 has been marked as a duplicate of this bug. ***

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