Kerberos as non-root

Ken Raeburn raeburn at MIT.EDU
Thu Oct 3 19:11:00 EDT 2002


"David E. Cross" <crossd at cs.rpi.edu> writes:
> I am considering making a very *very* simple change to the KDC/kadmind as
> follows:  start as root, bind any resources (files, network ports, etc).

Sounds like an excellent idea.  Aside from the privileged ports, I
don't think there's anything the KDC needs that requires root access.

> Also by having the kdc/kadmin running as "not root" you can still have the 
> important files only readable by root. An attacker then would not have 
> easy access to the database. They would need to do all database accesses
> through the compromised KDC, which isn't as easy as just downloading the
> entire DB.

I don't think it would add a lot of protection in this area.

For one thing, if the attackers can get in to the machine without
crashing both the KDC and kadmind processes, they could just attach to
one and use it to pull out the master key and database entries.  (In
the current KDC -- find the file descriptor open on the database, then
call lseek, fstat, malloc and read, and you've got the whole database
in memory; then open, write, close and maybe chmod to dump it out.)
It takes a little more work than your basic break-in, but it's not
impractical.

Also, database propagation to slave KDCs is done by replacing the old
database file with the new one and having the KDC process notice and
re-open it.  So the database file has to be accessible to whatever uid
the KDC runs under, unless that interaction is changed also.

If reducing the exposure of the database and master key to an attacker
is a goal, splitting the KDC into two parts would probably be
necessary, something like what the CITI folks did to incorporate a
tamper-proof card into their KDC.  The security-critical part could
run under a different uid than the part doing the basic network and
database i/o.

But simply switching everything but the port binding to use a non-root
uid is a good start.

Ken



More information about the krbdev mailing list