On Tue, 2012-01-31 at 13:58 +0100, Ondrej Valousek wrote:
> > I fail to see why non-root processes should be trying to
> > read /etc/krb5.keytab at all. You should be generating a per-service
> > keytab with only the keys necessary for that service to authenticate
> > itself to the KDC. So you might have /etc/dovecot/dovecot.keytab which
> > is readable only by the dovecot user.
> > The problem with allowing access to /etc/krb5.keytab is that it means
> > that an exploit in another process (especially a mail server!) could
> > gain access to the keys necessary to impersonate your host in kerberized
> > applications on the network. That's really dangerous.
> Right, but that's exactly what is happening with kerberized BIND,
> right? As far as I understand, you need to chown /etc/krb5.keytab to
> 'named' first.
Not at all, in freeipa we create a /etc/named/dns.keytab (or similar)
and we put there the keys for the DNS/fqdn@REALM principal.
> In general, you are probably right, the only problem is that most of
> the Linux kerberized services expect krb5.keytab in /etc.
/etc/krb5.keytab is simply the default keytab location, you just need to
set the KRB5_KTNAME env variable right before services startup (init
scripts or systemd unit files) to make them user a different default.
Some let you explicitly define the keytab location in their config to
avoid having to mess with environment variables.
> Moreover, in situation where winbind (or later maybe even sssd, for
> example) maintains the system Kerberos database, we would need some
> means to tell him to maintain more database files on multiple
> locations - and that is too messy.
These tools maintain only the host/ or at most the cifs/ keytab
The other keytabs are not, although with AD that's messy as AD aliases
all keys to the host/ one. That is a bad issue with AD that I plan to
fix in the spring via the gss-proxy project I am working on.
> Maybe a time to introduce some simple database layer on the top of
> the /etc/krb5.keytab which would handle the permissions correctly?
I know there isn't much info yet.
Some info is here, but also needs a bit of updating:
> Applications/services would need to talk to this layer and not
> krb5.keytab directly.
That's completely right, working on that :-)
Simo Sorce * Red Hat, Inc * New York
Freeipa-users mailing list