User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 Build Identifier: Every time I run Starcraft II, I get the attached SELinux warning. As far as I can tell, the correct course of action is to ignore it, since the program runs fine and disabling this would cause some unspecified security problem. What I'd like to suggest are two improvements to this warning: * Say what this is actually protecting against. I assume the average person doesn't know what the "mmap_zero" policy does, or what it protects them from. I know more about security than the average user, and I don't know what it does (making it harder to predict addresses to jump to?). Even something like, "this protects against a certain class of common exploits involving [very, very high level view], see [url] for more information". * Give people the information they need to make a decision about this. In my case this would be far less annoying if it said, "This warning is usually caused by wine. If you're not running wine, your computer may be under attack. If you are running wine and the program is crashing, you can disable this policy, but it will make your computer easier to exploit (see above). If your program is running as expected, you should ignore this warning." --- SELinux is preventing /usr/bin/wine-preloader from mmap_zero access on the memprotect . ***** Plugin mmap_zero (53.1 confidence) suggests ************************* If you do not think /usr/bin/wine-preloader should need to mmap low memory in the kernel. Then you may be under attack by a hacker, this is a very dangerous access. Do contact your security administrator and report this issue. ***** Plugin catchall_boolean (42.6 confidence) suggests ****************** If you want to control the ability to mmap a low area of the address space, as configured by /proc/sys/kernel/mmap_min_addr. Then you must tell SELinux about this by enabling the 'mmap_low_allowed' boolean. You can read 'unconfined_selinux' man page for more details. Do setsebool -P mmap_low_allowed 1 ***** Plugin catchall (5.76 confidence) suggests ************************** If you believe that wine-preloader should be allowed mmap_zero access on the memprotect by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep wine-preloader /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: /* removed */ Reproducible: Always Steps to Reproduce: 1. Install Fedora 2. Run basically anything in wine. Actual Results: Program runs. Expected Results: Program runs, but there's also a warning, but it has no information I can easily act on, except blindly clicking buttons hoping it will go away. There should either be no warning, or it should be useful.
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 ***