[Bug 1179820] New: Kerberos KDC connection limit too low

Nico Williams nico at cryptonector.com
Thu Jan 22 14:52:02 EST 2015


On Thu, Jan 22, 2015 at 11:19:49AM -0500, Greg Hudson wrote:
> On 01/22/2015 09:56 AM, Roland C. Dowdeswell wrote:
> > A simple heuristic approach that would likely do what you want
> > would be to simply check the fd returned by accept(2) and if it is
> > ``too close'' to the ulimit then switch off accepting connexions.
> 
> 1. We don't currently use getrlimit(), and beginning to do so would
> require thinking about its portability.  That's a source of complexity.

Or just garbage collect old[er] connections when EMFILE/ENFILE.  (That's
Roland's off-line suggestion to me.)

Roland's idea is probably easier to implement if you have plugins that
might make it difficult to distinguish resource limits/exhaustion errors
from other errors.

> 2. This method does not take into account memory limitations, only fd
> limitations.

Same thing here: hit resource limit -> close older connections (which
should free up some resources).

Of course, here it's harder to use getrlimit() and friends...

> 3. This method requires an estimate of how many fds the KDC might use
> during processing of currently pending requests.

Nah.  For Roland's proposal you'd need to define "close to limit" as
within some reasonable constant, say, 5, of the limit.

> 4. If we switch off accepting new connections, an attacker can DOS the
> TCP portion of the KDC by simply filling up the connection table and
> doing nothing.  If we discard old connections as we currently do, the
> attacker has to keep creating connections, and some legitimate requests
> might still get through.

They could always do that anyways.  The KDC could respond resource
exhaustion by randomly choosing to close the current connection or an
older one.  But at the end of the day, an attacker who can consume all
your available resources... will do it.

In any case, 45 is ridiculously small.  A dynamic self-tuning mechanism
is better than a configurable knob, and a configurable knob with a
reasonable default is better than a configurable knob that generally
needs tuning.

Nico
-- 


More information about the krbdev mailing list