Date: Thu, 4 Sep 2003 13:17:53 -0400 From: Tom Rhodes <trhodes@FreeBSD.org> To: Tillman Hodgson <tillman@seekingfire.com> Cc: FreeBSD-doc@FreeBSD.org Subject: Re: [Review Request] Kerberose 5 patch. Version two! Message-ID: <20030904131753.4e16c97c.trhodes@FreeBSD.org> In-Reply-To: <20030904114444.U21559@seekingfire.com> References: <20030903163616.04ac91aa.trhodes@FreeBSD.org> <20030904152353.GH25063@submonkey.net> <20030904111531.S21559@seekingfire.com> <20030904124922.009c69c1.trhodes@FreeBSD.org> <20030904114444.U21559@seekingfire.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 4 Sep 2003 11:44:44 -0600
Tillman Hodgson <tillman@seekingfire.com> wrote:
> On Thu, Sep 04, 2003 at 12:49:22PM -0400, Tom Rhodes wrote:
> > On Thu, 4 Sep 2003 11:15:31 -0600
> > Tillman Hodgson <tillman@seekingfire.com> wrote:
> > > 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.
>
> Thanks Tom!
>
> I promise to learn SGML (and not attempt to preach LaTeX ;-) ) sometime
> soon *grin*.
I like LaTeX, I think. :P
>
> > 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.
>
> I like it. The word "insist" might be a bit strong (it /is/ a good idea
> for some/most environments, after all). How does "prefer" sound?
>
> A pointer to section 2.14 of the Kerberos FAQ and the MIT install guide
> "Mapping Hostnames onto Kerberos Realms" section (both already in our
> references) which talk about DNS issues for multi-homed hosts and
> setting up DNS (respectively) might make sense here. The NetBSD
> reference that was previously mentioned could also come into play here.
Well, I removed insist. Actually, I came up with this:
<note>
<para>For large networks with a properly configured
<acronym>BIND</acronym> <acronym>DNS</acronym> server, the
above example could be trimmed to:</para>
<programlisting>[libdefaults]
default_realm = example.org</programlisting>
<para>With the following lines being appended to the
<hostid role="fqdn">exmple.org</hostid> zonefile:</para>
<programlisting>_kerberos._udp IN SRV 01 00 88 kerberos.example.org.
_kerberos._tcp IN SRV 01 00 88 kerberos.example.org.
_kpasswd._udp IN SRV 01 00 464 kerberos.example.org.
_kerberos-adm._tcp IN SRV 01 00 749 kerberos.example.org.
_kerberos IN TXT EXAMPLE.ORG.</programlisting></note>
This gives us a sentence which reads as "it could be done this way,
but you are not required to do so."
>
> > > > 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.
>
> I might be misreading that, so just to be safe I'll clarify: this
> problem doesn't affect the KDC, it affects all workstations.
>
> Changing the permissions on /tmp for all workstations might be a
> contentious recommendation. Most Kerberos applications will take an
> environment variable to tell them to look elsewhere for the ticket,
> though this isn't truly standardized and still doesnt' solve the "root
> user problem".
>
> I'm not sure that this is a problem that documentation can solve :-)
Then I'll ignore the change I was going to make and just leave the
paragraph as it was. Thanks!!
--
Tom Rhodes
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030904131753.4e16c97c.trhodes>