On Tue, 2012-01-31 at 07:32 -0500, Stephen Gallagher wrote:
> On Tue, 2012-01-31 at 10:22 +0100, Ondrej Valousek wrote:
> > 
> > > > Hey sounds good to me, just glad it is working for you :). The only
> > > > other question/suggestion I have is that it looks like you aren't
> > > > leveraging kerberos in your configuration for SSO, You might want to
> > > > think about doing this as it can be a pretty nice configuration.
> > > > 
> > > > Essentially you would just need to add service principles for the host
> > > > in the form of imap and or pop, and change the auth line in your dovecot
> > > > config to allow for gssapi auth, like so:
> > > > 
> > > > sed -i -r "s&(\smechanisms =).*&\1 gssapi plain&"
> > > > 
> > > > Then assuming your user has a ticket, and their client is properly
> > > > configured, they no longer need to do anything upon logging into their
> > > > system, kerb will auth the rest.
> > > > 
> > > > If you are on a multihomed system, you will need two additional changes,
> > > > service principles for the other host name, and the following 
> > > > modification:
> > > > sed -i -r 's&#auth_gssapi_hostname.*&auth_gssapi_hostname = $ALL&'
> > > > 
> > > > I got a little caught up when you referenced the /etc/krb5.keytab file
> > > > as possibly part of the problem so I thought this was more a kerb issue.
> > > > 
> > Exactly, I was confused by this as well - I would like to see this
> > working, too. But I would say we would need to do something with the
> > permissions on /etc/krb5.keytab which is now (by default) only
> > readable by root. We need to address this problem more in general as
> > when inegrating Bind DNS server, you hit the same thing.
> > I would say something like ACL entry would help.
> 
> 
> 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.

Just to make it clear how bad it is.
The host/ key is used to validate logins, if an attacker gets it it can
successfuly MITM a login attempt by hijacking KDC replies to AS-REQ and
TGS-REQ by forging a TGT and then forging a ticket for the host using
the host key.

It is *very* bad, so try to reduce the number of applications that can
access the host/ keys.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to