From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 20:11:20 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82C6216A41F for ; Wed, 31 Aug 2005 20:11:20 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2896843D45 for ; Wed, 31 Aug 2005 20:11:19 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j7VKBHeJ007241; Wed, 31 Aug 2005 13:11:17 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j7VKBGV0007240; Wed, 31 Aug 2005 13:11:16 -0700 Date: Wed, 31 Aug 2005 13:11:16 -0700 From: Brooks Davis To: Michael Bushkov Message-ID: <20050831201116.GH32477@odin.ac.hmc.edu> References: <20050827170633.Y5409@stinger.cc.rsu.ru> <43123F3B.8070002@FreeBSD.org> <20050829115740.N5409@stinger.cc.rsu.ru> <20050829163025.GA25664@dan.emsphone.com> <20050830172127.E5409@stinger.cc.rsu.ru> <20050831190059.GA23652@stack.nl> <20050831231233.T72814@stinger.cc.rsu.ru> <20050831194808.GA12742@stack.nl> <20050831235458.L72814@stinger.cc.rsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050831235458.L72814@stinger.cc.rsu.ru> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-current@freebsd.org, Dan Nelson , Jilles Tjoelker Subject: Re: [PATCH] caching daemon release and nsswitch patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 20:11:20 -0000 On Thu, Sep 01, 2005 at 12:00:09AM +0400, Michael Bushkov wrote: > On Wed, 31 Aug 2005, Jilles Tjoelker wrote: > > >On Wed, Aug 31, 2005 at 11:18:19PM +0400, Michael Bushkov wrote: > >>>On Tue, Aug 30, 2005 at 05:32:52PM +0400, Michael Bushkov wrote: > >>>>We can't ensure that, I guess. In the upcoming version (before the 1st > >>>>of > >>>>September), the cache would be per-user. This would solve all the > >>>>security > >>>>problems. In a little while, I'll implement the ability for cached to > >>>>act > >>>>as nscd. So you'll be able to choose the behaviour. > > > >>>What about setuid/setgid programs then? > > > >>>setuid root programs can use root's cache, perhaps a similar thing could > >>>be done for other setuid programs, but what about setgid? > > > >>>perhaps don't cache at all for set*id programs (issetugid(2))? > >>Per-user cache uses euid as the user identifier. So every setuid program > >>will use the cache, which corresponds to its euid. > >>But how can setgid affect the cache operations? Do you see some potential > >>issue? > > > >User X puts some garbled information in the cache for his uid, then > >starts a setgid program. That setgid program will use the bad data > >in the cache which is potentially exploitable. > Yes - you're right. I see 2 solutions: > > 1) The thing that you said - to turn off the caching for set*id programs > > 2) To separate users in the cache not only by their euid, but by their > euid and egid together. In this case, if user X poisons the cache and > starts the setgid program, then it will use the different (not poisoned) > cache. I don't think that such a partitioning will cause the cache to grow > too much. I'd be inclined toward the first option. Getting edge cases right for suid apps requires lots of thinking so I'd rather just not support the feature initially. Performance critical suid applications probably aren't too common anyway. -- Brooks