Bug 702020
| Summary: | selinux denial for httpd when it tries to access pki-ca (on a remote machine) | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Kashyap Chamarthy <kchamart> |
| Component: | doc-Identity_Management_Guide | Assignee: | Deon Ballard <dlackey> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | ecs-bugs |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.1 | CC: | alee, ckannan, dlackey, dpal, dwalsh, jgalipea, jskeoch, kevinu, syeghiay |
| Target Milestone: | rc | Keywords: | Documentation, Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-06-21 23:13:40 UTC | Type: | --- |
| 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: | 702988 | ||
|
Description
Kashyap Chamarthy
2011-05-04 14:47:06 UTC
So the workaround is to add the relevant selinux rule. You can do this following the instructions at http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/96/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Fixing_Problems-Allowing_Access_audit2allow.html Two ways: audit2allow -a -M revoker semodule -i revoker Or, you can set a selinux boolean: setsebool httpd_can_network_connect on actually that should be: semodule -i revoker.pp Since RHEL 6.1 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. I think this is a doc issue with the range of fixes being what Ade said. 9180 is a non-standard port which is why SELinux is complaining. This isn't really a bug per se, so much as a doc issue. You are trying to access a specific non-standard port that is protected by selinux and need to add a rule to allow this access. This is, I think, a fairly standard selinux operation? An example of when this happens, is when Kashyp was doing whatever testing he was doing with mod_revocator. Consquence: Access is denied to the port (9180). Workaround: See comment #2 above. Two ways are provided to allow the relevant access. Result: Access is provided. No restrictions. I checked on a 6.1 system with neither ipa or dogtag installed. There are several ports (including 9180) that appear to be defined as pki_ca_t. This means that the ports are defined within core selinux policy. As an aside, I confirmed with Kashyap that he used a 6.1 machine with only mod_revocator installed. This means that this is a core selinux policy bug. Either we need to remove the port designation from core selinux policy, or we need to add the relevant rules to allow mod_revocator to work. On a dogtag system, this is not an issue because the selinux policy generated eby dogtag on the fly creates rules for the required access. Dan, please update the policy. This is not an SELinux bug. If you want to install your package then you either need to tell apache it can connect to any port. Or you need to add a custom policy. We are not going to ship policy that lets every apache server connect to the pki_ca_port. corenet_tcp_connect_pki_ca_port(httpd_t) Development Management has reviewed and declined this request. You may appeal this decision by reopening this request. Then it is an IPA bug. This is not an IPA bug. We do not configure mod_revocator by default therefore we do not allow the port. As Ade said, this is a documentation issue. Anyone wanting to use the IPA CA for OCSP or CRL retrieval will need to LOCALLY allow Apache to communicate on that port as an HTTP client. Locally meaning "If you want to use IPA CA for OCSP or CRL retrieval, configure your client software to able to access the remote service. If the client is for example an Apache application leveraging mod_revocator the Selinux policies on the client should be adjusted to allow Apache access to the IPA server. By default SELinux policies would prevent such communication." Is this the correct statement? It is though I wonder if the word client is going to confuse people. They may not consider that mod_revocator in this case is the client. I tried to mock up something better but wasn't able to in any sort of concise way. Re-assigning to me as a doc bug. Setting to ON_QA for review for 6.2. This is a bulk change, so I'm not providing links at this time. If you need help finding the info, ping sunny-dee on #docs or email me. Thanks! Closing. |