Hi,

We've been running Kerberos for a number of years.  We've always run
all the processes (including kprop, kadmin, etc) as root.  A new group
has taken over running these machines and don't want to give the
Kerberos support people root access.  I've looked around but I can't
find out if Kerberos can run as a non-root user.

thanks,
ds
--
Dave Steiner
Identity Management, ESS
Rutgers University, Office of Information Technology

Dave <steiner.dave@gmail.com> writes:

> We've been running Kerberos for a number of years.  We've always run all
> the processes (including kprop, kadmin, etc) as root.  A new group has
> taken over running these machines and don't want to give the Kerberos
> support people root access.  I've looked around but I can't find out if
> Kerberos can run as a non-root user.

No reason that I can see provided that you find a way for the KDC to bind
to port 88 before dropping privileges.  But I don't think the code has any
built-in way of doing that other than starting the KDC as root.

Note, of course, that if you generally use Kerberos for authentication for
your systems, your operations group is being ridiculous here.  Any
Kerberos KDC administrator could just change the password of one of the
operations people and then gain root that way.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Russ Allbery <rra@stanford.edu> writes:

> Dave <steiner.dave@gmail.com> writes:
>
>> We've been running Kerberos for a number of years.  We've always run all
>> the processes (including kprop, kadmin, etc) as root.  A new group has
>> taken over running these machines and don't want to give the Kerberos
>> support people root access.  I've looked around but I can't find out if
>> Kerberos can run as a non-root user.
>
> No reason that I can see provided that you find a way for the KDC to bind
> to port 88 before dropping privileges.  But I don't think the code has any
> built-in way of doing that other than starting the KDC as root.

You can also run krb5kdc on an unprivileged port without running as
root, but that could require DNS SRV records or explicit configuration
on the clients.

> Note, of course, that if you generally use Kerberos for authentication for
> your systems, your operations group is being ridiculous here.  Any
> Kerberos KDC administrator could just change the password of one of the
> operations people and then gain root that way.

True, unless for some reason the ops people don't trust Kerberos for
authenticating logins to the host that runs the KDC.  It's still a
good security practice to avoid running any other services on a KDC
host though.

Tom Yu <tlyu@MIT.EDU> writes:
> Russ Allbery <rra@stanford.edu> writes:

>> Note, of course, that if you generally use Kerberos for authentication
>> for your systems, your operations group is being ridiculous here.  Any
>> Kerberos KDC administrator could just change the password of one of the
>> operations people and then gain root that way.

> True, unless for some reason the ops people don't trust Kerberos for
> authenticating logins to the host that runs the KDC.

Even then, it's a serious uphill battle to protect against an actual
attacker with access to the KDC.  They can silently compromise the account
of one of the people in operations and then Trojan ssh to sniff the root
password, just to pick one example.  Protecting yourself against attackers
with KDC access is, at most sites that use Kerberos, a lost cause.

> It's still a good security practice to avoid running any other services
> on a KDC host though.

Yeah, that plus the use of Kerberos for authentication anyway is why I've
not only never seen any point in running production KDCs as non-root
users, I've never seen any point in having anyone other than the KDCs
administer the system on which the KDCs run.  There's just no realistic
security gain; all these people tend to be able to access each other's
accounts with a modicum of work, so you may as well unify all the
operations so that you can minimize the footprint that way.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>