From owner-freebsd-doc@FreeBSD.ORG Thu Sep 4 10:44:46 2003 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3DA5416A4BF for ; Thu, 4 Sep 2003 10:44:46 -0700 (PDT) Received: from mail.seekingfire.com (coyote.seekingfire.com [24.72.10.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64EED43FE9 for ; Thu, 4 Sep 2003 10:44:45 -0700 (PDT) (envelope-from tillman@seekingfire.com) Received: from blues.seekingfire.prv (blues.seekingfire.prv [192.168.23.211]) by mail.seekingfire.com (Postfix) with ESMTP id 8CA93A7 for ; Thu, 4 Sep 2003 11:44:44 -0600 (CST) Received: (from tillman@localhost) by blues.seekingfire.prv (8.11.6/8.11.6) id h84Hiiq11285 for FreeBSD-doc@FreeBSD.org; Thu, 4 Sep 2003 11:44:44 -0600 Date: Thu, 4 Sep 2003 11:44:44 -0600 From: Tillman Hodgson To: FreeBSD-doc@FreeBSD.org Message-ID: <20030904114444.U21559@seekingfire.com> References: <20030903163616.04ac91aa.trhodes@FreeBSD.org> <20030904152353.GH25063@submonkey.net> <20030904111531.S21559@seekingfire.com> <20030904124922.009c69c1.trhodes@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030904124922.009c69c1.trhodes@FreeBSD.org>; from trhodes@FreeBSD.org on Thu, Sep 04, 2003 at 12:49:22PM -0400 X-Urban-Legend: There is lots of hidden information in headers Subject: Re: [Review Request] Kerberose 5 patch. Version two! X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2003 17:44:46 -0000 On Thu, Sep 04, 2003 at 12:49:22PM -0400, Tom Rhodes wrote: > On Thu, 4 Sep 2003 11:15:31 -0600 > Tillman Hodgson 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*. > Well, I have an idea on how to do this. Something like: > > > 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. > > > 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 :-) -T -- Look inside yourself and you can see the universe. - Zensunni Aphorism