Description of problem: SELinux is preventing php-fpm from using the 'execmem' accesses on a process. ***** Plugin catchall_boolean (89.3 confidence) suggests ****************** If you want to allow httpd to execmem Then you must tell SELinux about this by enabling the 'httpd_execmem' boolean. Do setsebool -P httpd_execmem 1 ***** Plugin catchall (11.6 confidence) suggests ************************** If you believe that php-fpm should be allowed execmem access on processes labeled httpd_t 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: # ausearch -c 'php-fpm' --raw | audit2allow -M my-phpfpm # semodule -X 300 -i my-phpfpm.pp Additional Information: Source Context system_u:system_r:httpd_t:s0 Target Context system_u:system_r:httpd_t:s0 Target Objects Unknown [ process ] Source php-fpm Source Path php-fpm Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.13.1-283.14.fc27.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 4.13.9-300.fc27.x86_64+debug #1 SMP Mon Oct 23 13:20:17 UTC 2017 x86_64 x86_64 Alert Count 1 First Seen 2017-10-29 15:36:15 +05 Last Seen 2017-10-29 15:36:15 +05 Local ID fa5434da-7834-48f1-931a-5da62d1c5d30 Raw Audit Messages type=AVC msg=audit(1509273375.859:1359): avc: denied { execmem } for pid=14746 comm="php-fpm" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_t:s0 tclass=process permissive=1 Hash: php-fpm,httpd_t,httpd_t,process,execmem Version-Release number of selected component: selinux-policy-3.13.1-283.14.fc27.noarch Additional info: component: selinux-policy reporter: libreport-2.9.2 hashmarkername: setroubleshoot kernel: 4.13.9-300.fc27.x86_64+debug type: libreport Potential duplicate: bug 1490115
***** Plugin catchall_boolean (89.3 confidence) suggests ****************** If you want to allow httpd to execmem Then you must tell SELinux about this by enabling the 'httpd_execmem' boolean. Do setsebool -P httpd_execmem 1
What are the consequences of this option? Why do I have to include options without clarification from the sealert why they are needed.
Description of problem: Printing a document using CUPS driver, over IPPS protocol, to a Xerox 7835 printer, using Xerox's PPD. Version-Release number of selected component: selinux-policy-3.13.1-283.17.fc27.noarch Additional info: reporter: libreport-2.9.3 hashmarkername: setroubleshoot kernel: 4.13.15-300.fc27.x86_64 type: libreport
(In reply to Lukas Vrabec from comment #1) > ***** Plugin catchall_boolean (89.3 confidence) suggests > ****************** > > If you want to allow httpd to execmem > Then you must tell SELinux about this by enabling the 'httpd_execmem' > boolean. > > Do > setsebool -P httpd_execmem 1 Mr. Vrabec, With all due respect to the important work you do, I must say that your answer to Mikhail is completely inappropriate for this venue, and because your action on the bug report was not clearly correct either. an explanation would have been in order. Your answer simply repeated to him what he already told you at the beginning of his bug report. One can reasonably assume that the writer already knows the contents of the bug report. But more than the obvious non sequitur of your answer, you should have explained why you believe it is not a bug. You yourself are the one of the maintainers of the selinux-policy packages, which means: 1. you also know of the related packages that *do* provide application-level policies; and 2. you are aware of the the RedHat SELinux wiki (https://fedoraproject.org/wiki/SELinux), which discusses, inter alia, how application developers can write and ship an appropriate policy with their application. That the alert is not a bug is not obvious. (Pardon the double negative.) A PHP process accessing or wrtiing to a file marked http_t is what php does. The P in LAMP server should "Just Work(tm)". As is documented in the selinux-policy-doc package, which contains the httpd_php_selinux man page, the default policy explicitly provides for a very flexible php selinux policy. Why *this* process should not be part of the *httpd_php_t* policy is an open question in the eyes of the hapless mortals running servers. (As an aside, I note that system administrators who care about security are constantly having to fight with bosses, salesmen, and accountants that give not a damn about keeping the servers safe. They would happily tell sysadmins simply to set selinux to permissive and be done with it. Mikhail is fighting the good fight and should be treated respectfully.) Reasonable minds can differ on whether this is a bug, however, and you must make difficult decisions sometimes. If you, in your good judgment, do not think it is a bug against selinux-policy itself, then: 1. Consider that sealert/setroubleshoot may have a bug in sending the bug report to you instead of the violating application (php in this case). 2. A statement of why the policy is not included in the base policy package would be helpful to this user (and all the others who are likely to come behind him). If the question comes up frequently, you could even add something to the selinux-policy man page, the writing of which page you are undoubtedly doing inasmuch as the package ships without a man page or any other documentation. 3. You might even simply assign the bug to the appropriate package maintainer for him/her to dispose. With much gratefulness for the work you do. Loye Young
Loye, You have no idea the volume of bug reports from users that never read the analysys. So before chastising Lukas, understand the load that he is under. BTW I would have done the same thing. Mikail the consequences of this is that a "hacked version" of httpd will no longer have the SELinux protection on execmem attacks. execmem blocks a hacked process from being able to write-to and execute the same memory segment. A common attack on applications is called buffer overflow, but to make it effective the hacker needs to be able write to memory and then execute it. Bottom line, is the code that you are using to cause this issue is not written as well as it should be. I don't see a big risk in disabling this boolean, since other parts of SELinux will continue to protect you.