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 normally. 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? See https://fedorahosted.org/gss-proxy/ I know there isn't much info yet. Some info is here, but also needs a bit of updating: http://k5wiki.kerberos.org/wiki/Projects/ProxyGSSAPI > Applications/services would need to talk to this layer and not > krb5.keytab directly. That's completely right, working on that :-) Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-users mailing list Freeipafirstname.lastname@example.org https://www.redhat.com/mailman/listinfo/freeipa-users