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.
Bug 1008777 - AVC denial when GSS Proxy attempts to create /var/tmp/HTTP_0
Summary: AVC denial when GSS Proxy attempts to create /var/tmp/HTTP_0
Keywords:
Status: CLOSED DUPLICATE of bug 1194299
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gssproxy
Version: 7.0
Hardware: Unspecified
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Robbie Harwood
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-09-17 04:30 UTC by Jan Pazdziora (Red Hat)
Modified: 2015-08-20 21:59 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-08-19 15:31:59 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1168962 0 high CLOSED gssproxy is not working with httpd on ppc64 and s390x 2021-02-22 00:41:40 UTC

Internal Links: 1168962

Description Jan 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.
Comment 2 Daniel Walsh 2013-10-07 12:50:41 UTC 
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?
Comment 3 Daniel Walsh 2013-10-07 12:52:58 UTC 
9a971c5e09d656caa650c378bd42d34a74a9dd0b fixes this in git.
Comment 13 Jan Pazdziora (Red Hat) 2014-03-11 16:18:47 UTC 
Updating summary to make it clear that as of last package versions, the authentication actually works.
Comment 15 Jan Pazdziora (Red Hat) 2014-12-04 11:15:00 UTC 
The same issue in Fedora 21: bug 1170576 now.
Comment 16 Daniel Walsh 2014-12-05 11:56:54 UTC 
What AVC are you getting?
Comment 17 Jan Pazdziora (Red Hat) 2014-12-05 12:20:24 UTC 
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
Comment 19 Daniel Walsh 2014-12-09 01:20:47 UTC 
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.
Comment 20 Simo Sorce 2014-12-10 03:25:42 UTC 
(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 23 Jan Pazdziora (Red Hat) 2015-02-19 14:00:27 UTC 
Alternative approach to addressing the issue is to merely change gssproxy packaging, bug 1194299.
Comment 25 Dmitri Pal 2015-04-15 16:53:38 UTC 
Upstream ticket:
https://fedorahosted.org/gss-proxy/ticket/130
Comment 26 Dmitri Pal 2015-04-15 16:54:07 UTC 
Upstream ticket:
https://fedorahosted.org/gss-proxy/ticket/145
Comment 27 Robbie Harwood 2015-08-19 15:31:59 UTC 
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 ***
Note You need to log in before you can comment on or make changes to this bug.