Bug#975344: libapache-mod-auth-kerb: Uses Internal Krb5 APIs [test this patch please]

2020-11-30 Thread Sam Hartman
control: tags -1 pending

I've uploaded to delayed/3, using your minimal patch.

Thanks.


--Sam



Bug#975344: libapache-mod-auth-kerb: Uses Internal Krb5 APIs [test this patch please]

2020-11-26 Thread Damyan Ivanov
-=| Damyan Ivanov, 23.11.2020 22:16:43 +0200 |=-
> -=| Sam Hartman, 23.11.2020 10:02:34 -0500 |=-
> > Here's a patch that I believe will get libapache-mod-auth-kerb 
> > working with the latest krb5.  I'll go upload a krb5 that fixes the 
> > breaks relationship.
> > 
> > I'd appreciate it if someone who actually uses 
> > libapache-mod-auth-kerb will test this patch.
> > If it gets tested, I'll NMU.  If not, I'll ask the release team to
> > remove libapache-mod-auth-kerb from testing.
> 
> I'll try to find time to test the patch tomorrow (UTC+02).

A bit late, but I succeeded in testing the patch. Upgrading libkrb5-3 
and its dependencies to 1.18.3-4 doesn't break apache2 with 
mod-auth-kerb anymore. Moreover, the basic functionality (user 
authentication against a domain controller) works as before.

I am attaching a minimal patch, with the following changes compared to 
Sam's patch:

 - removed another instance of 'have_rcache_type' usage
 - removed all but the changes in debian/changelog, 
   debian/patches/serries and the real patch to mod_auth_kerb.c that 
   lives under debian/patches/.

I think this patch can be used for a clean NMU.

Cheers,
Damyan
diff --git a/debian/changelog b/debian/changelog
index b04ca6a..f621e17 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+libapache-mod-auth-kerb (5.4-2.5) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Always assume none replay cache type is present, Closes: #975344
+
+ -- Sam Hartman   Mon, 23 Nov 2020 09:34:53 -0500
+
 libapache-mod-auth-kerb (5.4-2.4) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --git a/debian/patches/0011-Always-use-NONE-replay-cache-type.patch b/debian/patches/0011-Always-use-NONE-replay-cache-type.patch
new file mode 100644
index 000..71aaf40
--- /dev/null
+++ b/debian/patches/0011-Always-use-NONE-replay-cache-type.patch
@@ -0,0 +1,73 @@
+From: Sam Hartman 
+Date: Mon, 23 Nov 2020 09:30:22 -0500
+Subject: Always use NONE replay cache type
+
+It's 2020.  Any MIT Kerberos in the wild supports the none replay
+cache type.  The previous code used an internal function to detect
+that replay cache type; that function is no longer available.
+Instead, assume it is present.
+
+An alternative would be to enable the default replay cache.  It was
+originally disabled because of problems between Microsoft
+authenticators and 2004-era MIT Kerberos 1.3.  That's probably a good
+idea.  It probably closes off security attacks, although analyzing the
+impact of replays in cases where neither channel binding nor
+per-message services are used is difficult.  I believe that a replay
+cache is not strictly necessary in the common configuration where
+mod-auth-kerb is used over a TLS-protected connection where the client
+properly verifies the TLS certificate presented by the server prior to
+sending a GSS token.
+
+I have elected not to enable replay cache to affect a minimal change.
+---
+ src/mod_auth_kerb.c | 23 +--
+ 1 file changed, 1 insertion(+), 22 deletions(-)
+
+--- a/src/mod_auth_kerb.c
 b/src/mod_auth_kerb.c
+@@ -2057,27 +2057,6 @@ kerb_authenticate_user(request_rec *r)
+return ret;
+ }
+ 
+-static int
+-have_rcache_type(const char *type)
+-{
+-   krb5_error_code ret;
+-   krb5_context context;
+-   krb5_rcache id = NULL;
+-   int found;
+-
+-   ret = krb5_init_context();
+-   if (ret)
+-  return 0;
+-
+-   ret = krb5_rc_resolve_full(context, , "none:");
+-   found = (ret == 0);
+-
+-   if (ret == 0)
+-  krb5_rc_destroy(context, id);
+-   krb5_free_context(context);
+-
+-   return found;
+-}
+ 
+ /*** 
+  Module Setup/Configuration
+@@ -2139,7 +2118,7 @@ kerb_module_init(server_rec *dummy, pool
+ #ifndef HEIMDAL
+/* Suppress the MIT replay cache.  Requires MIT Kerberos 1.4.0 or later.
+   1.3.x are covered by the hack overiding the replay calls */
+-   if (getenv("KRB5RCACHETYPE") == NULL && have_rcache_type("none"))
++   if (getenv("KRB5RCACHETYPE") == NULL )
+   putenv(strdup("KRB5RCACHETYPE=none"));
+ #endif
+ }
+@@ -2181,7 +2160,7 @@ kerb_init_handler(apr_pool_t *p, apr_poo
+ #ifndef HEIMDAL
+/* Suppress the MIT replay cache.  Requires MIT Kerberos 1.4.0 or later.
+   1.3.x are covered by the hack overiding the replay calls */
+-   if (getenv("KRB5RCACHETYPE") == NULL && have_rcache_type("none"))
++   if (getenv("KRB5RCACHETYPE") == NULL)
+   putenv(strdup("KRB5RCACHETYPE=none"));
+ #endif
+ #ifdef STANDARD20_MODULE_STUFF
diff --git a/debian/patches/series b/debian/patches/series
index d2c7173..9848ef3 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -9,3 +9,4 @@ remove_bashism.patch
 gssapi_delegation.patch
 apache24.patch
 mod_auth_kerb-krb5_kt_close.patch
+0011-Always-use-NONE-replay-cache-type.patch


Bug#975344: libapache-mod-auth-kerb: Uses Internal Krb5 APIs [test this patch please]

2020-11-23 Thread Damyan Ivanov
-=| Sam Hartman, 23.11.2020 10:02:34 -0500 |=-
> Here's a patch that I believe will get libapache-mod-auth-kerb 
> working with the latest krb5.  I'll go upload a krb5 that fixes the 
> breaks relationship.

Thank you, Sam.

> I'd appreciate it if someone who actually uses 
> libapache-mod-auth-kerb will test this patch.
> If it gets tested, I'll NMU.  If not, I'll ask the release team to
> remove libapache-mod-auth-kerb from testing.

I'll try to find time to test the patch tomorrow (UTC+02).

About removing auth-kerb from testing, this may be not so bad. I see 
Fedora have removed it, with auth-gssapi as a functional replacement. 
I plan to test that too at some point.


-- Damyan



Bug#975344: libapache-mod-auth-kerb: Uses Internal Krb5 APIs [test this patch please]

2020-11-23 Thread Sam Hartman
control: tags -1 patch

Here's a patch that I believe will get libapache-mod-auth-kerb working
with the latest krb5.  I'll go upload a krb5 that fixes the breaks
relationship.

I'd appreciate it if someone who actually uses libapache-mod-auth-kerb
will test this patch.
If it gets tested, I'll NMU.  If not, I'll ask the release team to
remove libapache-mod-auth-kerb from testing.

I apologize for the vcs churn in the patches.



patch
Description: Binary data


signature.asc
Description: PGP signature