Bug 527147 - setroubleshoot: SELinux is preventing /usr/bin/wine-preloader "mmap_zero" access on <Unknown>.
Summary: setroubleshoot: SELinux is preventing /usr/bin/wine-preloader "mmap_zero...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 12
Hardware: i386
OS: Linux
low
medium
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: setroubleshoot_trace_hash:16524e93ed8...
: 527408 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-10-05 00:28 UTC by cam
Modified: 2010-01-19 19:41 UTC (History)
7 users (show)

Fixed In Version: 3.6.32-69.fc12
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-01-19 19:41:12 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description cam 2009-10-05 00:28:16 UTC
The following was filed automatically by setroubleshoot:

Summary:

SELinux is preventing /usr/bin/wine-preloader "mmap_zero" access on <Unknown>.

Detailed Description:

SELinux denied access requested by wine-preloader. The current boolean settings
do not allow this access. If you have not setup wine-preloader 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:wine_t:s0-s0:c0.c1023
Target Context                unconfined_u:unconfined_r:wine_t:s0-s0:c0.c1023
Target Objects                None [ memprotect ]
Source                        wine-preloader
Source Path                   /usr/bin/wine-preloader
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           wine-core-1.1.29-3.fc12
Target RPM Packages           
Policy RPM                    selinux-policy-3.6.32-11.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-48.fc12.i686 #1 SMP Fri Sep
                              25 17:13:30 EDT 2009 i686 i686
Alert Count                   6
First Seen                    Tue 29 Sep 2009 01:23:18 AM BST
Last Seen                     Tue 29 Sep 2009 01:23:26 AM BST
Local ID                      0b33af58-d87a-4b08-8001-a0f76bc9c00c
Line Numbers                  

Raw Audit Messages            

node=(removed) type=AVC msg=audit(1254183806.666:33): avc:  denied  { mmap_zero } for  pid=2332 comm="wine-preloader" scontext=unconfined_u:unconfined_r:wine_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:wine_t:s0-s0:c0.c1023 tclass=memprotect

node=(removed) type=SYSCALL msg=audit(1254183806.666:33): arch=40000003 syscall=90 success=no exit=-13 a0=bf84fe20 a1=0 a2=bf84fe20 a3=5a items=0 ppid=2331 pid=2332 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="wine-preloader" exe="/usr/bin/wine-preloader" subj=unconfined_u:unconfined_r:wine_t:s0-s0:c0.c1023 key=(null)



Hash String generated from  selinux-policy-3.6.32-11.fc12,catchall_boolean,wine-preloader,wine_t,wine_t,memprotect,mmap_zero
audit2allow suggests:

#============= wine_t ==============
allow wine_t self:memprotect mmap_zero;

Comment 1 Miroslav Grepl 2009-10-05 11:41:47 UTC
Did you try to execute what setroubleshoot suggests:

# setsebool -P mmap_low_allowed 1

Comment 2 Miroslav Grepl 2009-10-06 10:07:43 UTC
*** Bug 527408 has been marked as a duplicate of this bug. ***

Comment 3 cam 2009-10-06 20:17:01 UTC
I've never run wine_preloader directly so I'm not sure how this is triggered - however I imagine some changes to the wine or selinux packages would be appropriate.

Otherwise, are you seriously suggesting that every end user should see the bug info pop up and learn enough about selinux to decide if they need / want to 'setsebool -P mmap_low_allowed 1'?

I don't see how this could be marked CLOSED; NOTABUG.

Comment 4 Eric Paris 2009-10-06 20:52:49 UTC
Yes.  I am suggesting that every user should decide if they really want to disable system security features in order to run Windows applications.  I do NOT want the system to disable them automatically.

I agree that the message you get is not the best and even tech savy linux guru's probably wouldn't understand the implications of the given operation.  I will work with our setroubleshoot group to get better text to explain to users what they are doing, but no, changing SELinux to allow this automatically is without question not the right thing to do.  period.

Comment 5 cam 2009-10-06 21:12:21 UTC
I'm troubled by this:

If a user installs a package that requires a security feature to be disabled, IMHO they should have an opportunity to do it as part of the installation rather than at some later arbitrary point - for me I saw this just after I logged in. They might decide not to bother at this point.

If a security relaxation is required I thought the whole point of selinux was to be able to do it in a fine grained way. Doesn't setting a boolean equate to a system wide setting? Can't something be done to allow just wine_preloader to do whatever it needs to do?

What about things like NFS, if I install that, do I have to jump through separate hoops to actually use it, eg. tweak selinux, punch holes through firewalls, etc. etc.? I would hope not. Try not to have judgement coloured by this being Windows related, as repugnant as it is to run buggy Windows software it is useful :)

Comment 6 Eric Paris 2009-10-06 21:28:07 UTC
"IMHO they should have an opportunity to do it as part of the installation
rather than at some later arbitrary point"

I install WINE on all of my machines, it's part of my default kickstart.  But I do not want to disable a security feature just because it's installed.  I really think doing it at first use is the right time.

"for me I saw this just after I logged in"

That's a bit odd.  Were you trying to run a Windows app?  If not, you might have a more serious issue at hand.  It shouldn't happen unless you try to run a windows app.

"Doesn't setting a boolean equate to a system wide setting? Can't something be done to allow just wine_preloader to do whatever it needs to do?"

It does equate to a system wide setting.  We have one big global knob that says "mmap_zero may no happen anywhere on the system" or "mmap_zero may happen only in select cases."  This is the knob you are turning.  The reason we need this knob is because users in Fedora policy are unconfined.  They are this way people users scream a lot louder when we try to confine them   :)  An unconfined user can easily get around any security restriction from SELinux (it's called 'unconfined' for a reason)  see dan's blog for a discussion:

http://danwalsh.livejournal.com/30084.html

When you turn the big global knob you actually only allow mmap_zero for wine and for vbetool.  But there are known exploit programs in the wild which masquerade as wine to get around this restriction.  Being an unconfined user that masquerading is actually quite simple.  You can see a long discussion of this (and how SELinux was in some ways worse than non-SELinux systems) at

http://eparis.livejournal.com

"What about things like NFS, if I install that, do I have to jump through
separate hoops to actually use it, eg. tweak selinux, punch holes through
firewalls, etc. etc.? I would hope not."

You'd be mistaken.  You do have to configure your firewall to make NFS servers work.  Same way you have to configure your firewall to make a web server work.  You have to configure SELinux to allow your web server to send e-mail.  Sadly installation and configuration are not the same.


I've suggested some changes to the setroubleshoot text and I've ask that they include a one click button to fix the selinux issue rather than forcing you to the command line.  My text suggestion was as follows:

Title: SELinux has prevented wine from performing an unsafe memory operation.

SELinux denied an operation requested by wine-preloader, a program used
to run Windows applications under Linux.  This program is known to use
an unsafe operation on system memory but so are a number of
malware/exploit programs which masquerade as wine.  If you were
attempting to run a Windows program your only choices are to allow this
operation and reduce your system security against such malware or to
refrain from running Windows applications under Linux.  If you were not
attempting to run a Windows application this indicates you are likely
being attacked by some for of malware or program trying to exploit your
system for nefarious purposes.

If you decide to continue to run the program in question you will need
to allow this operation.  This can be done on the command line by
executing:

# setsebool -P mmap_low_allowed 1

Or by clicking the "Allow it" button below.  You should also see:

http://wiki.winehq.org/PreloaderPageZeroProblem

Which outlines the other problems wine encounters due to its unsafe use
of memory and solutions to those problems.

[include additional information here like raw AVC message]



What do you think?

Comment 7 cam 2009-10-06 22:19:14 UTC
I take your point about unconfined users masquerading as wine - and I've read Dan's blog. It does seem a shame to reduce security for every process in order to run wine - I'm not sure I appreciate the reasoning behind that decision (I'll try to read up).

From the end user point of view, I think your text is good. Would it be possible to change "Allow it" to "Allow it this time" / "Always ask me"? I think that would be more secure than allowing something 'for ever more' and wouldn't present the user with a difficult question along the lines of "will running Spotify just this once make my system security weak from here on in?"

Maybe my example of NFS was a bad one - because like Apache it does need significant thoughtful configuring to be useful. Wine however is the sort of thing an end user can expect to work out of the box. Whatever can be done to make the selinux config less painful is surely worth the effort.

Comment 8 Daniel Walsh 2009-10-15 19:25:41 UTC
Well then every time you execute wine it will blow up the first time and generate an AVC.  The funny thing is not all wine apps need mmap_zero.  Probably just the ones that use older libraries.

Comment 9 Eric Paris 2009-10-15 19:35:58 UTC
I think dan was responding to "Would it be
possible to change "Allow it" to "Allow it this time" / "Always ask me"?"

We don't really have the ability to do that, and I'm not convinced training people to push buttons is a good idea.  I do however this that presenting users with the choice is the right thing if it is explained in a user friendly manor....

Training the user to enter passwords and push buttons does not help security.

Comment 10 cam 2009-10-15 21:43:27 UTC
I'm sorry but it looks like the easy options give us this:

0. install a program accepting that it might not work out of the box
1. don't run the program you wanted to on the grounds that it might be unsafe
2. permanently turn off a global security setting in order to run the program, even if you might run the program only once and not like it

In other words, a collection of security and usability fails.

Would it be possible to have metadata in packages, so a well packaged (signed) application could request boolean settings it requires to run? The information could then be presented in a user friendly way to someone installing a package. The installer could prompt the user to adjust security settings so that the package can be used if they wish to at that time. There could also be intelligence in system-config-selinux to inform the user about the booleans that they are turning on and off. eg.
mmap_low_allowed [x] /required/ (tooltip: this may be needed by the package wine)
mmap_elephants [ ] /not used/ (tip: this is not needed by any installed software and should be left off for improved security)

Comment 11 Bug Zapper 2009-11-16 13:15:55 UTC
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 12 r6144 2009-12-27 05:22:46 UTC
I'm seeing this error, I have not disabled this protection, SELinux is in enforcing mode, and my wine applications still run fine.  Maybe only DOS or 16-bit Windows applications are affected?  If so, perhaps the warning text should be revised.  If the user uses wine but does not run DOS/16-bit applications with it, he should be offered the option to ignore this warning ("dontaudit" or maybe logging only) as it can be quite annoying; if he does, I guess it would still be marginally safer to limit this mmap_zero capability only to specific contexts.

Okay, as a more thorough solution, maybe when a user-space process mmaps the zero-page, it should be unmapped every time the process enters the kernel and only remapped when a page fault occurs (in userspace or when the kernel is actually trying to access user-space memory).  This would slow down such a process a bit, but won't affect anything else.

Comment 13 Daniel Walsh 2009-12-30 00:44:19 UTC
Eric, Anything we can do here

Comment 14 r6144 2009-12-30 01:44:07 UTC
Currently I just use a local policy with

# mmap_zero doesn't really seem necessary for my wine applications
dontaudit wine_t self:memprotect mmap_zero;

It seems to silent the alerts without turning off the protection.  It might be better to make this option available in the sealert GUI; somehow "Ignore Alert" doesn't work for me.  (But what if the user actually needs to turn off the protection entirely afterwards?  Maybe wine itself can notify the users if this is likely necessary?)

Comment 15 Daniel Walsh 2009-12-30 01:49:53 UTC
Could you try the setroubleshoot in updates-testing.

yum update setrouble\* --enablerepo=updates-testing

Comment 16 Daniel Walsh 2009-12-30 01:50:41 UTC
The dontaudit rule is fine.  I guess we could add a boolean for this rule.

wine_dontaudit_mmap_zero?

Comment 17 Eric Paris 2010-01-11 14:16:08 UTC
The suggestion in comment #14 comes up occasionally but isn't viable.  Consider a multithreaded application in which one thread allocates this page 0 and then pounds on it so it is mapped.  A second thread enters the kernel, triggers the unknown bug which uses the 0 page, and wins.  Sorry....

A way to shut up the denial does seem reasonable....

Comment 18 Daniel Walsh 2010-01-11 14:34:43 UTC
Miroslav could you add to wine.te for F12


## <desc>
## <p>
## Ignore wine mmap_zero errors
## </p>
## </desc>
#
gen_tunable(wine_mmap_zero_ignore, false)


tunable_policy(`wine_mmap_zero_ignore',`
	allow wine_t self:memprotect mmap_zero;
')


Add to wine.if

	tunable_policy(`wine_mmap_zero_ignore',`
		allow $1_wine_t self:memprotect mmap_zero;
	')

Comment 19 Miroslav Grepl 2010-01-11 15:13:48 UTC
Fixed in selinux-policy-3.6.32-69.fc12

Comment 20 Fedora Update System 2010-01-12 23:27:18 UTC
selinux-policy-3.6.32-69.fc12 has been pushed to the Fedora 12 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: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-0362

Comment 21 Fedora Update System 2010-01-19 19:40:09 UTC
selinux-policy-3.6.32-69.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.


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