Re: Put a limit to ticket life span.

[Mats Erik Andersson]

lördag den 27 oktober 2012 klockan 12:42 skrev Russ Allbery detta:
> Mats Erik Andersson <address@hidden> writes:
> 
> > I have brought this up before:
> 
> >   A native Solaris' Kerberos ticket request, will be granted
> >   by "shishid" with a life span of 25 years, since libshishi
> >   does not perform sanitation. It is "shishid" that malfunc-
> >   tions, not the external client!
> 
> > The following patch resets the requested expiration time for
> > any request that asks for more than a five-fold of the default
> > life span, simply by resetting the interval to the configured
> > default value. I have tested this with "kinit" on OpenIndiana
> > and "shishid" on Debian.
> 
> Assuming that I understood this correctly (I've not studied the code)....
> 
> Maximum ticket lifetime should really be something that the KDC
> administrator can configure, since this is closely tied with local
> security policies and with the basic security tradeoff of Kerberos (short
> ticket expirations but no revocation facility).  For both MIT and Heimdal,
> the maximum ticket lifetime is configurable per principal.
> 
> Assuming 5x the default expiration caps the problem, but isn't the
> configuration that I suspect most people use.  Most sites in my experience
> set the maximum ticket lifetime to the same as the default and use
> renewable tickets if they want to allow tickets to last longer than that.

The problem is this:

  * Solaris' kinit does not per se, unless told by 'kinit -l 27m',
    send any time limit information to "shishid".

  * shishid is not clever enough, or was not programmed carefully
    enough, to recognize the absence of a time limit field. It will
    therefore set an infinite time limit, resulting in a validity
    for some 25 years with present epoch counters.

Seen from the programmer's horizon, in "lib/internal.h" there is library
internal access to the configurable field "handle->timelimit". However,
"src/kdc.c" is not allowed to access this. Let me trace some calls:

  * A request sent without a field "till", will cause shishi_kdcreq_tillc()
    to return "(time_t) -1", i.e., infinite time in all senses.

  * In "src/kdc.c, lines 783--787" this infinite value is uncritically
    passed on

     
shishi_encticketpart_endtime_set(shishi_generalized_time(shishi_kdcrec_tillc()))

    leading to the present mishap.

The patch in this thread intended to address this, and the matter still
is bound by the administrator's decision. Perhaps the factor five should
be replaced by ten as breaking point, but it was chosen as a possible
mode of detecting an exsessive time limit. I do not now for sure. Let me
add that another idea for a solution was stated in [1], but it never caught
any attention.

Luckily, collecting my thoughts for this answer, I have found I third
way of attack, which seems to be what you are looking for. It copes
in the desired way with the Solaris clients, and leaves all other
untouched.

Best regards,
  Mats Erik Andersson

[1] http://lists.gnu.org/archive/html/help-shishi/2012-08/msg00058.html


>From 849163741ad8efbcfccbba989eebee3c3f5149f2 Mon Sep 17 00:00:00 2001
From: Mats Erik Andersson <address@hidden>
Date: Sat, 27 Oct 2012 23:14:43 +0200
Subject: [PATCH] kdcreq: Initiate ticket life as finite.

Some clients transmit requests without the field "till".
Assign a ticket life span for such requests based on
the servers configuration.
---
 lib/kdcreq.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/lib/kdcreq.c b/lib/kdcreq.c
index affef41..87b4279 100644
--- a/lib/kdcreq.c
+++ b/lib/kdcreq.c
@@ -616,7 +616,7 @@ shishi_kdcreq_tillc (Shishi * handle, Shishi_asn1 kdcreq)
 {
   char *till;
   size_t tilllen;
-  time_t t = (time_t) - 1;
+  time_t t = time (NULL) + handle->ticketlife;
   int res;
 
   res = shishi_kdcreq_till (handle, kdcreq, &till, &tilllen);
-- 
1.7.2.5