Bug 1047417

SELinux tries to protect against this attack as its considered dangerous since wine applications require mmap_min_addr protection causing a mmap_zero AVC denial [1][2] 

Based on the alert, if your app is working, then ignore the message. If its forcing you to run in permissive mode then set the boolean.

[root@localhost ~]# getsebool -a | grep mmap_low
mmap_low_allowed --> off

[root@localhost ~]# setsebool -P mmap_low_allowed 1


[1] http://danwalsh.livejournal.com/37067.html
[2] http://lwn.net/Articles/342573

(In reply to Simon Sekidde from comment #1)
> SELinux tries to protect against this attack as its considered dangerous
> since wine applications require mmap_min_addr protection causing a mmap_zero
> AVC denial [1][2] 
> 
> Based on the alert, if your app is working, then ignore the message. If its
> forcing you to run in permissive mode then set the boolean.
> 
> [root@localhost ~]# getsebool -a | grep mmap_low
> mmap_low_allowed --> off
> 
> [root@localhost ~]# setsebool -P mmap_low_allowed 1
> 
> 
> [1] http://danwalsh.livejournal.com/37067.html
> [2] http://lwn.net/Articles/342573

 I've already determined that in my case I should ignore this warning. My concern with the bug report is that I had to figure it out through Google searches, since the actual warning isn't useful (what is mmap_zero? what does it protect against? is it important?). People like me will eventually figure it out that way, but a lot of people don't know how to use search engines (sadly), so the warning should have enough information so people can make a reasonably well informed decision.

This LWN article talks about why the mmap_zero policy is implemented the way it is, but like the SELinux warning, it doesn't say *why it exists*. That's the important important piece of information this warning could provide, unless your goal is for users to read this and immediately click the "turn this off and stop bugging me" button.

As a "for more information" URL, this is better than those two: http://eparis.livejournal.com/606.html

But it would be better if there was a description of why this was implemented in the first place.

My suggestions:

Write a new setroubleshoot plugin which checks as best it can if the task in question is wine and outputs different text for wine vs non-wine.  We know that the denial should be ignored by the user for wine.  We can probably even tell them how to add a dontaudit rule in the wine plugin.

As for why mmap_zero exists:

The Linux kernel restricts userspace programs from using memory addresses in the range 0 through mmap_min_addr.  The value for mmap_min_addr is not necessarily easy to determine.  It is usually somewhere between 4k and 64k and there are different values enforced based on root/non-root and based on SELinux context.

The kernel restricts this access because allowing userspace to place arbitrary information in those areas makes a rather large class of kernel vulnerabilities, particularly NULL pointer dereferences, significantly easier to exploit.  By restricting userspace programs from mapping that memory range we make it much harder to exploit this class of kernel bugs.

Already have a boolean for this.
 getsebool -a | grep wine
wine_mmap_zero_ignore --> off

Although it does not cover unconfined_t.

We used to have a lot more verbiage on setroubleshoot, but this caused users to be more confused.

Again, I'm not talking about how to fix it, I'm saying there's not enough information for users to determine if they *should*. It doesn't necessarily just more information, just the right information:

  * If you're getting this warning and it's not from wine, your system is probably being attacked.
  * If you're getting this warning from wine, and your program isn't working, you can disable this, but it will reduce security for the entire computer, because the SELinux allows any application to masquerade as wine.
  * It would be really nice if there was some information about *why* mmap_zero exists (not *what* it is, since that's not important to end-users), like, "mmap_zero makes null pointer dereferencing more difficult to exploit" (I think this is what it does?), but if you think that would confuse people that's fine.

Feel free to close this if you don't think this would be useful.

No I think this is a good conversation.  I wish the kernel would not report these to the system since DAC would block the mmap_zero access anyways, then we would not even need any check.  Then if you ran a process with privs and got mmap_zero, then it would be significant.

Paul Moore: Can you do what dan wants in comment #6.  Just move the check after the cap call.  (cc casey on the patch so if he still has his stacking series he can make that change there too) ?

Dan, in comment #4 you state:

> Already have a boolean for this.
>  getsebool -a | grep wine
> wine_mmap_zero_ignore --> off
> 
> Although it does not cover unconfined_t.

Enabling this boolean appears to have worked to silence these warnings up through F19, but it seems to no longer work in F20.  Did something change with the selinux policy to affect this, or did something change with wine's context?

Actually adding Paul Moore to CC so he can see Eric's question in comment #7.

(In reply to Josh Boyer from comment #9)
> Actually adding Paul Moore to CC so he can see Eric's question in comment #7.

Thanks :)

I'll work on it; updates once I have a patch.

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs.

Fedora 20 has now been rebased to 3.13.4-200.fc20.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.

The problem still exists.

*** This bug has been marked as a duplicate of bug 1013466 ***