From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 20:17:13 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 E099616A41F for ; Wed, 31 Aug 2005 20:17:13 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from mail.r61.net (mail.r61.net [195.208.245.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DA2A43D46 for ; Wed, 31 Aug 2005 20:17:12 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from stinger.cc.rsu.ru (stinger.cc.rsu.ru [195.208.252.82]) by mail.r61.net (8.13.4/8.13.4) with ESMTP id j7VKGrNu023238; Thu, 1 Sep 2005 00:16:53 +0400 (MSD) (envelope-from bushman@rsu.ru) Date: Thu, 1 Sep 2005 00:21:05 +0400 (MSD) From: Michael Bushkov X-X-Sender: bushman@stinger.cc.rsu.ru To: Brooks Davis In-Reply-To: <20050831201116.GH32477@odin.ac.hmc.edu> Message-ID: <20050901001719.Q72814@stinger.cc.rsu.ru> 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> <20050831201116.GH32477@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.86.2, clamav-milter version 0.86 on asterix.r61.net X-Virus-Status: Clean X-Spam-Status: No, score=-5.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on asterix.r61.net 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:17:14 -0000 Hello! >>> 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. Ok - I'm absolutely agreed. I'll do it this way. With best regards, Michael Bushkov Rostov State University