Bug 1008777 - AVC denial when GSS Proxy attempts to create /var/tmp/HTTP_0
AVC denial when GSS Proxy attempts to create /var/tmp/HTTP_0
Status: CLOSED DUPLICATE of bug 1194299
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gssproxy (Show other bugs)
7.0
Unspecified Linux
high Severity high
: rc
: ---
Assigned To: Robbie Harwood
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-17 00:30 EDT by Jan Pazdziora
Modified: 2015-08-20 17:59 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-08-19 11:31:59 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jan Pazdziora 2013-09-17 00:30:21 EDT
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 08:50:41 EDT
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 08:52:58 EDT
9a971c5e09d656caa650c378bd42d34a74a9dd0b fixes this in git.
Comment 13 Jan Pazdziora 2014-03-11 12:18:47 EDT
Updating summary to make it clear that as of last package versions, the authentication actually works.
Comment 15 Jan Pazdziora 2014-12-04 06:15:00 EST
The same issue in Fedora 21: bug 1170576 now.
Comment 16 Daniel Walsh 2014-12-05 06:56:54 EST
What AVC are you getting?
Comment 17 Jan Pazdziora 2014-12-05 07:20:24 EST
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-08 20:20:47 EST
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-09 22:25:42 EST
(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 2015-02-19 09:00:27 EST
Alternative approach to addressing the issue is to merely change gssproxy packaging, bug 1194299.
Comment 25 Dmitri Pal 2015-04-15 12:53:38 EDT
Upstream ticket:
https://fedorahosted.org/gss-proxy/ticket/130
Comment 26 Dmitri Pal 2015-04-15 12:54:07 EDT
Upstream ticket:
https://fedorahosted.org/gss-proxy/ticket/145
Comment 27 Robbie Harwood 2015-08-19 11:31:59 EDT
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.