[Review Request] Kerberose 5 patch. Version two!

[Tom Rhodes]

On Thu, 4 Sep 2003 11:44:44 -0600
Tillman Hodgson <tillman at 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 at 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