Hide Forgot
Description of problem: When trying GSS Proxy installation with Apache (described at https://fedorahosted.org/gss-proxy/wiki/Apache), I get AVC denials of the GSS Proxy creating file in /var/tmp and the authentication fails. Version-Release number of selected component (if applicable): # rpm -q gssproxy selinux-policy gssproxy-0.2.3-6.el7.x86_64 selinux-policy-3.12.1-77.2.el7.noarch How reproducible: Deterministic. Steps to Reproduce: 1. Set IPA server and IPA enrolled client, on the client install gssproxy, httpd, and mod_auth_kerb using the https://fedorahosted.org/gss-proxy/wiki/Apache instructions. 2. kinit admin on the IPA server 3. run curl --negotiate -u : http://the-client/private Actual results: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>500 Internal Server Error</title> </head><body> <h1>Internal Server Error</h1> <p>The server encountered an internal error or misconfiguration and was unable to complete your request.</p> <p>Please contact the server administrator at root@localhost to inform them of the time this error occurred, and the actions you performed just before this error.</p> <p>More information about this error may be available in the server error log.</p> </body></html> Expected results: OK Additional info: AVC denials is type=AVC msg=audit(1379391391.441:148): avc: denied { create } for pid=24914 comm="gssproxy" name="HTTP_0" scontext=system_u:system_r:gssproxy_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file This is a RHEL 7 variant https://fedorahosted.org/gss-proxy/ticket/100. Please note that on Fedora 19, the AVC denial is logged but it does not prevent the operation, on RHEL 7 the operation actually fails.
Is this the only replay cache that this will create? Isn't this this a little dangerous from a known name created in /tmp? Shouldn't root processes now be creating replay caches in a directory like /var/cache/kerberos? Since they are root?
9a971c5e09d656caa650c378bd42d34a74a9dd0b fixes this in git.
Updating summary to make it clear that as of last package versions, the authentication actually works.
The same issue in Fedora 21: bug 1170576 now.
What AVC are you getting?
In Fedora 21, it's type=AVC msg=audit(1417690943.120:572): avc: denied { create } for pid=32439 comm="gssproxy" name="HTTP_0" scontext=system_u:system_r:gssproxy_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file permissive=0
Jan this indicates a whell known name file HTTP_0 is being created by a privileged process. Which would be an instant CVE. HTTP_0 should be created under /run not in /var/tmp. Or gssproxy should be creating /var/tmp/HTTP_23 -- system_u:object_r:krb5_host_rcache_t:s0 /var/tmp/HTTP_48 -- system_u:object_r:krb5_host_rcache_t:s0 With the proper UID ownership.
(In reply to Daniel Walsh from comment #19) > Jan this indicates a whell known name file HTTP_0 is being created by a > privileged process. Which would be an instant CVE. HTTP_0 should be > created under /run not in /var/tmp. > > Or gssproxy should be creating > /var/tmp/HTTP_23 -- system_u:object_r:krb5_host_rcache_t:s0 > /var/tmp/HTTP_48 -- system_u:object_r:krb5_host_rcache_t:s0 > > > With the proper UID ownership. Dan, the rcache cannot be in /run as it needs to survive a reboot (or you could theorethically cause a reboot and then perform replay attacks within the 5 minutes window). libkrb5 will do this for any service by default, it creates names according to this pattern: /var/tmp/<service>_<uid> It creates files like this with flags = O_WRONLY|O_CREAT|O_TRUNC|O_EXCL|O_BINARY I do not think it would be a CVE, but it does cause issues. I am opening a GSS-Proxy ticket to always set the rcache in a gss-proxy controlled, private directory, under the assumption that when you use GSS-Proxy you do not give the keys to anyone else. Of course admins will be able to override as needed. Also note that "proper UID ownership" is completely wrong here, a reply cache works only if *all* users of the key use the same rcache, otherwise you can cross-attack services, by replaying the packets sent to one onto the other, and for the HTTP case this would just work and get you authenticated due to the fact that HTTP-Negotiate is a bad spec and is subject to replay attacks. In fact this is another reason to just keep the rcache within GSS-Proxy and use GSS-Proxy if multiple services need to use the same keytab.
Alternative approach to addressing the issue is to merely change gssproxy packaging, bug 1194299.
Upstream ticket: https://fedorahosted.org/gss-proxy/ticket/130
Upstream ticket: https://fedorahosted.org/gss-proxy/ticket/145
Upstream tickets 130 and 145 have been closed by 4474bf5d9bb8830fecdb91774f6a3540a7c788da. We may revisit this in the future but for now the fix for 1194299 should apply here as well. *** This bug has been marked as a duplicate of bug 1194299 ***