[Review Request] Kerberose 5 patch. Version two!

Tom Rhodes trhodes at FreeBSD.org
Thu Sep 4 17:25:46 UTC 2003


On Thu, 4 Sep 2003 11:15:31 -0600
Tillman Hodgson <tillman at seekingfire.com> wrote:

> On Thu, Sep 04, 2003 at 04:23:53PM +0100, Ceri Davies wrote:
> > On Wed, Sep 03, 2003 at 04:36:16PM -0400, Tom Rhodes wrote:
> > > All,
> > > 
> > > Ok, after finally digging through the large amount of comments in
> > > my email, and finding some free time to actually apply them, I have
> > > produced another version.  This mixes comments from everyone who
> > > send any, and I hope this looks good.
> > 
> > Tom,
> > 
> > I forwarded this to my brother, who recently set up a Kerberos5 installation
> > (albeit on NetBSD), and he came back with the attached comments.
> > 
> > Hope they help.
> > 
> > Ceri
> 
> > 
> > * Ceri Davies <setantae at submonkey.net> [0902 14:02]:
> > 
> > Ta for that, it all looks good. I'm surprised by 3 bits though.
> > [ I assume you have the same Heimdal distro as us,if you don't
> > that would explain 2) and 3) ]
> > 
> > 1) "   For purposes of demonstrating a Kerberos installation, the various
> >    namespaces will be handled as follows:
> >      * The DNS domain (``zone'') will be example.org.
> >      * The Kerberos realm will be example.org.
> > 
> >      Note: Please use real domain names when setting up Kerberos even if
> >      you intend to run it internally. This avoids DNS problems and
> >      assures interoperation with other Kerberos realms.
> > "
> > I know it's only a convention, but I'd still put the realm name in caps.
> 
> I agree - my original draft had it in all caps. I suspect it got lost
> when the .prv TLDs were changed to .org.

I've already done this in my new diff.

> 
> > 2) "10.7.2 Setting up a Heimdal KDC
> > 
> >    Next we will set up your Kerberos config file, /etc/krb5.conf:
> > [libdefaults]
> >     default_realm = example.org
> > .
> > .
> > .
> > "
> > 
> > If you set up BIND properly, that's all you need in krb5/conf, see:
> <snip>
> 
> I can see your point. I use DNS for my own realms and it does work quite
> well.
> 
> My arguments for doing it the krb5.conf way:
> 
> * You still require a minimal krb5.conf in any case, so putting the
>   server information in there results in fewer installation steps. This
>   isn't what I do for a large production environment, but it is what
>   I'd do for a short tutorial.
> 
> * I wanted to avoid creating dependencies - the user may not want to
>   use bind.
> 
> * The DNS method tends to break kadmin if you run multiple realms off of
>   the same KDC. Explaining how to run kadmind on alternate ports is
>   beyond the scope of a Handbook chapter IMO.

Well, I have an idea on how to do this.  Something like:

<note>
  <para>When using Kerberos in a large network, and insist on using
     DNS services, then the following information could be added to
     the DNS configuration: ...

With the correct markup of course.

> 
> Would a reference to Kerberos and DNS work?
> 
> > 3) "10.7.8.2 Kerberos is intended for single-user workstations
> > 
> >    In a multi-user environment, Kerberos is less secure. This is because
> >    it stores the tickets in the /tmp directory, which is readable by all
> >    users. If a user is sharing a computer with several other people
> >    simultaneously (i.e. multi-user), it is possible that the user's
> >    tickets can be stolen (copied) by another user."
> > 
> > If the files are world-readable in /tmp then I agree,
> > but to be honest that's a bug that shouldbefixed.
> 
> It's not probably not completely fixable - whoever has root powers has
> the capability to "become" any user by using their Kerberos ticket.
> Granted, root has that power already but this extends it beyond the
> local machine. Users may not expect (or want) that.
> 

Perhaps we could recommend that /tmp have different permissions set?
Although, I have never ran a Kerberos server I do not want to just give
a set of permissions without knowing how they would affect Kerberos.

-- 
Tom Rhodes



More information about the freebsd-doc mailing list