gssproxy

#101 KrbLocalUserMapping does not work with with Apache & GSS-Proxy
Closed: Fixed Opened by amessina.

Closed: Fixed
Reopen Issue

When attempting to enable GSS-Proxy & [wiki:Apache], I find that the !KrbLocalUserMapping configuration option does not work. This is an imporant part of the configuration options, as not all web applications properly support !username@REALM.TLD style usernames, so I need to be able to say Require user username instead of Require user !username@REALM.TLD in some cases. I'm using gssproxy-0.2.3-6.fc19.1.x86_64, httpd-2.4.6-2.fc19.x86_64 and mod_auth_kerb-5.4-24.fc19.x86_64.

<Location /redacted>
  SSLRequireSSL
  AuthType Kerberos
  AuthName "Login"
  KrbAuthoritative On
  KrbLocalUserMapping On
  KrbServiceName HTTP/example.com@EXAMPLE.COM
  Require user username
</Location>

AH01631: user username@EXAMPLE.COM\x02s: authorization failure for /redacted
AH01663: access to /redacted failed, reason: user 'username@EXAMPLE.COM\x02' does not meet 'require'ments for user to be allowed access
AH01631: user username@EXAMPLE.COM\x02: authorization failure for "/redacted": 
AH01663: access to /redacted failed, reason: user 'username@EXAMPLE.COM\x02IN1' does not meet 'require'ments for user to be allowed access
AH01631: user username@EXAMPLE.COM\x02IN1: authorization failure for "/redacted": 
AH01663: access to /redacted failed, reason: user 'username@EXAMPLE.COM\x7f' does not meet 'require'ments for user to be allowed access
AH01631: user username@EXAMPLE.COM\x7f: authorization failure for "/redacted": 
AH01663: access to /redacted failed, reason: user 'username@EXAMPLE.COM\x02' does not meet 'require'ments for user to be allowed access

Sorry it took so long, but in order to fix this bug I needed to also add a feature to libkrb5 to allow me to specify none as the rcache.

The bug you are hitting here is due to mod_auth_kerb being buggy and assuming that buffers returned by gss_display_name) are always zero terminated strings. They are not in the API contract, but in order to avoid this class of issues with misbehaving applications I now have a patch to gssproxy's mechglue layer that will insure gss_display_name() returns zero terminated strings even if it shouldn't be required to.

However even if you resolve this problem you will then hit another bug in mod_auth_kerb (or apache, not sure which) where the whole request is reprocessed twice. This causes a replay cache error, because gss_accept_sec_context is called again with the same input packet.

mod_auth_kerb works around that [ opening itself to replay attacks :-( ] by simply disabling replay caches in apache completely. But the call that mod_auth_kerb uses is local to the process and does not extend to the gssproxy process, which still enforces replay attack checks.

The short term, and insecure way to handle this is by running gssproxy with the environment variable KRB5RCACHETYPE=none
This disables replay cache for every gssproxy client.

I have sent a patch upstream to allow passing the rcache type the credentials store interface, so hopefully MIT 1.13 will allow you to specify "cred_store = rcache:none:none" only for the service that handles the httpd keytab.

I will open bugs against mod_auth_kerb to try to resolve these issues upstream so that we can stop disabling the replay cache at some point.

Thanks, simo. This may also be related to another mod_auth_kerb issue I am having, which I reported against mod_auth_kerb back in September, but haven't heard anything: https://bugzilla.redhat.com/show_bug.cgi?id=1012665.

Can you comment?

Replying to [comment:7 amessina]:

Thanks, simo. This may also be related to another mod_auth_kerb issue I am having, which I reported against mod_auth_kerb back in September, but haven't heard anything: https://bugzilla.redhat.com/show_bug.cgi?id=1012665.

Can you comment?

That issue does not look like it is connected specifically with S4U2Proxy. Sounds like a naming issue between your server and the name in the keytab. Not related with this bug anyhow.

Pushed the fix from the mailinglist to master, can this ticket be closed then ?

Although the rcache problem is not fixed yet, that one requires changes to libkrb5, but no changes to gssproxy except for a configuration change.

We can open a new ticket about rcache to follow that up maybe ?

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1053730

Replying to [comment:5 simo]:

The short term, and insecure way to handle this is by running gssproxy with the environment variable KRB5RCACHETYPE=none
This disables replay cache for every gssproxy client.

I have sent a patch upstream to allow passing the rcache type the credentials store interface, so hopefully MIT 1.13 will allow you to specify "cred_store = rcache:none:none" only for the service that handles the httpd keytab.

I will open bugs against mod_auth_kerb to try to resolve these issues upstream so that we can stop disabling the replay cache at some point.

Simo, would you be able to post the links to the upstream patches/bug reports? Rob Crittenden has been working on a fix for https://bugzilla.redhat.com/show_bug.cgi?id=1012665 and if he rolls up a new build, I'd like to see if your patches here may be included.

Replying to [comment:5 simo]:

However even if you resolve this problem you will then hit another bug in mod_auth_kerb (or apache, not sure which) where the whole request is reprocessed twice. This causes a replay cache error, because gss_accept_sec_context is called again with the same input packet.

mod_auth_kerb works around that [ opening itself to replay attacks :-( ] by simply disabling replay caches in apache completely. But the call that mod_auth_kerb uses is local to the process and does not extend to the gssproxy process, which still enforces replay attack checks.

I have sent a patch upstream to allow passing the rcache type the credentials store interface, so hopefully MIT 1.13 will allow you to specify "cred_store = rcache:none:none" only for the service that handles the httpd keytab.

I will open bugs against mod_auth_kerb to try to resolve these issues upstream so that we can stop disabling the replay cache at some point.

I see https://github.com/krb5/krb5/commit/7dad0be, which is great and looks like it's upstream. Do you think this type of thing is a reasonable back-port to krb5-1.12 (and Fedora 19) since "KRB5RCACHETYPE=none" for gssproxy is quite insecure?

Patch pushed to master: d78ad1f

I created this Fedora bugzilla for the backports:
https://bugzilla.redhat.com/show_bug.cgi?id=1056078

Metadata Update from @amessina:
- Issue assigned to simo
- Issue set to the milestone: 2014 January
Metadata
None
None
None
Normal
defect
gssproxy daemon
https://bugzilla.redhat.com/show_bug.cgi?id=1053730
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.