[Pkg-openldap-devel] Heimdal changes

[Gabor Gombas]

On Fri, Nov 30, 2007 at 03:48:19PM -0800, C.J. Adams-Collier wrote:

> > I modified my krb5.conf file so that heimdal stores its principals in an
> > LDAP data store.  A peculiarity of this configuration is that kadmind
> > expects the access control file to be named after the LDAP dn of the
> > principal container node and to be in the current directory:<<EOF
> >
> > cjac at kerberos:~$ ls -l /etc/heimdal-kdc/*.acl
> > -rw-r--r-- 1 root root 156 Nov  8 18:00 /etc/heimdal-kdc/kadmind.acl
> > lrwxrwxrwx 1 root root  28 Nov  8 17:31
> > /etc/heimdal-kdc/ldap:ou=KerberosPrincipals,dc=cls2,dc=colliertech,dc=
> > org.acl -> /etc/heimdal-kdc/kadmind.acl
> > EOF
> >
> > In order to set $PWD to the correct value, inetd would need to call a
> > wrapper which does the chdir(2) and exec(3)

Is this still the case with Heimdal 1.0? If it is, I'd suggest reporting it
upstream. No daemon should depend on the current directory.

> > At this point, it seems that kadmind and kpasswd should be de-coupled
> > from kdc and moved into their own packages.  I can imagine many use
> > cases where administrators wouldn't feel comfortable opening a TCP port
> > for remote administration of kerberos principals, and "slave" servers
> > should not run kpasswd.  Allowing sysadmins to choose not to install the
> > daemons seems a useful feature.

Quite the contrary. You want everything installed on the slaves in case
the master dies and you have to do a failover. Maybe add a low-priority
debconf question whether this will be the master or a slave and
configure the kadmind/kpasswdd daemons appropriately.

> > Currently, all heimdal servers run as root.  Yipe.  We should probably
> > create a system user and group as well as an SELinux MAC policy.
> > This /is/ a network authentication infrastructure, after all.

IMHO if the KDC is compromised then whether the intruder gets root or
not is the least of your worries. You must assume that the complete
database was stolen and they're happily cracking the master key so you
must re-key every principal. Re-installing the KDC from scratch is about
half an hour (you do not run _anything_ else on it, right?),
re-generating and re-distributing the host keys and issuing new
passwords for users may take days or weeks depending on the number of
principals.

> > While going through all of this, I considered requirements to ease the
> > process of modifying the heimdal packages to configure the system to use
> > alternative principal sources.

What do you mean by that?

> > Is it possible to have one package query
> > another's entries in the database?  How about making modifications to
> > another's configuration?  In order to store to OpenLDAP, heimdal would
> > benefit from being able to discover some system settings:
> >
> > * the configured LDAP base DN

Which one? A single KDC instance can serve multiple realms using
multiple databases (well, you need some small patches for 0.7; they
should be included in 1.0 - I'll find out once I upgrade). Or different
kdc/kadmind/kpasswdd instances may run on the same machine bound to
different IP addresses.

> > * LDAP bind dn and password capable of creating the KerberosPrincipals
> > ou and a bind dn for the heimdal daemons' access to principals

Huh? You want to discover a _password_?!? If that password is stored
anywhere else than the kdc's configuration that would be quite a serious
misconfiguration...

> > Additionally, the package would need to cause some modifications
> > to /etc/default/slapd and /etc/ldap/slapd.conf, which are owned by the
> > slapd package.

That would be a very _BAD_ thing to do. Mucking with other packages'
config files only increases the possibility that something will go wrong
if the admin already did non-trivial modifications to those files.

> > If heimdal is configured to store principals to LDAP, removal of slapd
> > would break the system's kerberos settings, unless principals were
> > dumped to heimdal's native database and the /etc/krb5.conf were updated
> > to reflect the change.

Well, the UNIX philosophy is to let sysadmins shot themselves in the
foot if they want to. Do not employ clueless sysadmins.

> > I would like to see a simple set of regression tests run after
> > (re)configuration of slapd and heimdal packages.  This would ensure that
> > the heimdal user is able to access and modify principals.  There should
> > also be a rollback mechanism in case the regression tests fail.  I'd
> > hate to see an automated update cause a kerberos outage until a human
> > was able to fix the problem.

Automated update? On a KDC?!?! No way! An update can _ALWAYS_ go wrong
and can _ALWAYS_ cause breakage, so

- no sane man wants to do it on the master before being absolutely sure
  that it worked on a replica
- no sane man wants to do it at a time when there are no sysadmins near
  the console

Gabor

-- 
     ---------------------------------------------------------
     MTA SZTAKI Computer and Automation Research Institute
                Hungarian Academy of Sciences
     ---------------------------------------------------------