From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 21 04:38:26 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E05F716A4BF for ; Thu, 21 Aug 2003 04:38:26 -0700 (PDT) Received: from episec.com (episec.com [198.78.65.141]) by mx1.FreeBSD.org (Postfix) with SMTP id 5804D43F93 for ; Thu, 21 Aug 2003 04:38:26 -0700 (PDT) (envelope-from edelkind-freebsd-hackers@episec.com) Received: (qmail 54050 invoked by uid 1024); 21 Aug 2003 11:36:55 -0000 Date: Thu, 21 Aug 2003 07:36:55 -0400 From: ari To: freebsd-hackers@freebsd.org Message-ID: <20030821113655.GX55671@episec.com> Mail-Followup-To: ari , freebsd-hackers@freebsd.org, flowpriv@episec.com References: <20030817181315.GL55671@episec.com> <20030821054402.8B9582A7EA@canning.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030821054402.8B9582A7EA@canning.wemm.org> cc: flowpriv@episec.com Subject: Re: [future patch] dropping user privileges on demand X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2003 11:38:27 -0000 peter@wemm.org said this stuff: > ari wrote: > > Currently, root is the only user that can actually drop significant > > privileges, as root is the only user that has access to such functions. > > This is flawed --- any user should be able to relinquish his privileges, > > and i've begun a patch to put this into effect. > > > > However, the fact that this is a security-related kernel feature > > modification warrants peer-review, in both design and implementation. > > It would be unwise of me to create the patch without consulting such. > > > > The web page that discusses the patch may be found at: > > > > http://www.episec.com/people/edelkind/patches/kernel/flowpriv/ > > > > I welcome any discussion and criticism. > > The biggest risk is that you may have aquired something priviliged in your > process memory space or file descriptor table. If you are then fully > unpriviliged, then things like ptrace(), core dumps etc, become a minefield. > For example, if a process did a getpwnam() before dropping privs, then > it may have a cached copy of the secret master.passwd data in memory. > > Anyway, thats something to keep in mind. True, but you have this problem if you don't drop privileges, as well. The programmer must account for such things, either way. However, since even root-owned processes will be able to drop most system call privileges, programmers must be careful not to lull themselves into a false sense of security if, for example, dumping core is still an option. Dumping core should be disabled with filesystem writes, however, and ptrace should be included in a class of items to disable. ari