Subject: krb5kdc and kadmind could drop privileges after binding

A Debian user requested that krb5kdc and kadmind support dropping
privileges after binding to network ports and run as a non-root user
with access to the KDC database.  This isn't particularly compelling for
sites where the KDC holds the keys to everything anyway, but if one is
using a KDC for a guest realm, for a specific purpose, or in some other
more limited situation, this provides some additional security
protection.  It also provides some protection against unsophisticated
attackers who know how to use a root exploit but who don't have the
resources or knowledge to make use of access to the KDC database.

See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477309 for the
original report.

From: Ken Raeburn <raeburn@MIT.EDU>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5955] krb5kdc and kadmind could drop privileges after binding 
Date: Tue, 29 Apr 2008 13:13:21 -0400
CC: 477309@bugs.debian.org
RT-Send-Cc: 

> A Debian user requested that krb5kdc and kadmind support dropping
> privileges after binding to network ports and run as a non-root user
> with access to the KDC database.  This isn't particularly compelling
> for
> sites where the KDC holds the keys to everything anyway, but if one is
> using a KDC for a guest realm, for a specific purpose, or in some
> other
> more limited situation, this provides some additional security
> protection.  It also provides some protection against unsophisticated
> attackers who know how to use a root exploit but who don't have the
> resources or knowledge to make use of access to the KDC database.
>
> See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477309 for the
> original report.

True, after binding ports we may not need privileges.  Note, too,
though, that with SRV records or config file specs you can specify a
non-privileged port for clients to talk to, and run the KDC programs
entirely without privileges.  That's how we do our basic testing.

Unfortunately, I've heard that Microsoft clients ignore the port
number indicated in SRV records and always use port 88, so if Windows
clients are an issue, it could be a problem.  A firewall config on the
KDC that redirects UDP port 88 to whatever non-privileged port could
help with that, too, though it's kind of an ugly workaround.  And if
anyone puts a port-88 hole in their company firewall for Kerberos, it
may still block Kerberos traffic to another randomly chosen port.

(And yes, I agree with Russ's assessment in his message in the Debian
tracking system, that it's probably going to be low-priority for us,
but a good patch would be welcome.)

--
Ken Raeburn, Senior Programmer
MIT Kerberos Consortium