Did you try to execute what setroubleshoot suggests:

# setsebool -P mmap_low_allowed 1

*** Bug 527408 has been marked as a duplicate of this bug. ***

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.

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.

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 :)

"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?

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.

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.

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.

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)

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'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.

Eric, Anything we can do here

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?)

Could you try the setroubleshoot in updates-testing.

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

The dontaudit rule is fine.  I guess we could add a boolean for this rule.

wine_dontaudit_mmap_zero?

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....

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;
	')

Fixed in selinux-policy-3.6.32-69.fc12

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

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.