Bug 1700758
| Summary: | SELinux is preventing httpd from map access on the chr_file /dev/zero | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Lukas Slebodnik <lslebodn> |
| Component: | selinux-policy | Assignee: | Lukas Vrabec <lvrabec> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | high | ||
| Version: | rawhide | CC: | awilliam, dwalsh, lvrabec, mgrepl, plautrba, zpytela |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | openqa | ||
| Fixed In Version: | selinux-policy-3.14.4-12.fc31 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-04-29 18:10:38 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1644937 | ||
I am not sure whether it is a general issue for httpd but happens in case of ipa-server setup.
[root@nec-em25 ~]# systemctl restart httpd
Job for httpd.service failed because the control process exited with error code.
See "systemctl status httpd.service" and "journalctl -xe" for details.
[root@nec-em25 ~]# ausearch -m avc
----
time->Wed Apr 17 06:32:03 2019
type=AVC msg=audit(1555497123.706:713): avc: denied { map } for pid=35594 comm="httpd" path="/dev/zero" dev="devtmpfs" ino=1030 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:zero_device_t:s0 tclass=chr_file permissive=1
----
time->Wed Apr 17 06:32:24 2019
type=AVC msg=audit(1555497144.246:722): avc: denied { map } for pid=35908 comm="httpd" path="/dev/zero" dev="devtmpfs" ino=1030 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:zero_device_t:s0 tclass=chr_file permissive=0
I assume it might be related to openssl/mod_ssl based on httpd logs [root@nec-em25 ~]# > /var/log/httpd/error_log [root@nec-em25 ~]# systemctl restart httpd Job for httpd.service failed because the control process exited with error code. See "systemctl status httpd.service" and "journalctl -xe" for details. [root@nec-em25 ~]# cat /var/log/httpd/error_log [Wed Apr 17 06:39:08.706193 2019] [core:notice] [pid 36603:tid 140040011964736] SELinux policy enabled; httpd running as context system_u:system_r:httpd_t:s0 [Wed Apr 17 06:39:08.707751 2019] [suexec:notice] [pid 36603:tid 140040011964736] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Wed Apr 17 06:39:08.707999 2019] [core:emerg] [pid 36603:tid 140040011964736] (13)Permission denied: AH00023: Couldn't create the ssl-cache mutex AH00016: Configuration Failed Yes, openQA tests are seeing this too. Proposing as an F31 Beta blocker per https://fedoraproject.org/wiki/Fedora_30_Beta_Release_Criteria#FreeIPA_server_requirements - "The requirements from the Basic criteria must be met without workarounds being necessary". The requirements from the Basic criterion include "It must be possible to configure a Fedora Server system installed according to the above criteria as a FreeIPA domain controller, using the official deployment tools provided in the distribution FreeIPA packages..." commit 627ada3ccd7ceb3473673a38533a0a5747a733e8 (HEAD -> rawhide)
Author: Lukas Vrabec <lvrabec>
Date: Thu Apr 18 10:07:54 2019 +0200
Allow httpd_t doman to read/write /dev/zero device BZ(1700758)
commit 2cec77e00cf137056b24f8b73c19602c2c4939a4 (HEAD -> rawhide)
Author: Lukas Vrabec <lvrabec>
Date: Thu Apr 18 10:08:43 2019 +0200
Update dev_rw_zero() interface by adding map permission
FreeIPA tests on current Rawhide compose passed, so this does indeed appear fixed. |
SELinux is preventing httpd from map access on the chr_file /dev/zero. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that httpd should be allowed map access on the zero chr_file 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 'httpd' --raw | audit2allow -M my-httpd # semodule -X 300 -i my-httpd.pp Additional Information: Source Context system_u:system_r:httpd_t:s0 Target Context system_u:object_r:zero_device_t:s0 Target Objects /dev/zero [ chr_file ] Source httpd Source Path httpd Port <Unknown> Host nec-em25.testrelm.test Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.14.4-11.fc31.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name nec-em25.testrelm.test Platform Linux nec-em25.testrelm.test 5.1.0-0.rc5.git1.1.fc31.x86_64 #1 SMP Tue Apr 16 17:15:04 UTC 2019 x86_64 x86_64 Alert Count 2 First Seen 2019-04-17 06:32:03 EDT Last Seen 2019-04-17 06:32:24 EDT Local ID 37d0b5cb-89ab-430f-8ee5-52af3a9953d4 Raw Audit Messages type=AVC msg=audit(1555497144.246:722): avc: denied { map } for pid=35908 comm="httpd" path="/dev/zero" dev="devtmpfs" ino=1030 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:zero_device_t:s0 tclass=chr_file permissive=0 Hash: httpd,httpd_t,zero_device_t,chr_file,map