Bug 1008777

Summary:	AVC denial when GSS Proxy attempts to create /var/tmp/HTTP_0
Product:	Red Hat Enterprise Linux 7	Reporter:	Jan Pazdziora (Red Hat) <jpazdziora>
Component:	gssproxy	Assignee:	Robbie Harwood <rharwood>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	7.0	CC:	amessina, dpal, dwalsh, ebenes, gdeschner, jpazdziora, mmalik, pkis, rharwood, rmainz, ssorce
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-08-19 15:31:59 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:

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 ***