Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionJan Pazdziora (Red Hat)
2013-09-17 04:30:21 UTC
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?
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.
Comment 23Jan Pazdziora (Red Hat)
2015-02-19 14:00:27 UTC
Alternative approach to addressing the issue is to merely change gssproxy packaging, bug 1194299.
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 ***