From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 21 05:52:00 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 4A1CC16A4BF for ; Thu, 21 Aug 2003 05:52:00 -0700 (PDT) Received: from episec.com (episec.com [198.78.65.141]) by mx1.FreeBSD.org (Postfix) with SMTP id 9B78543F3F for ; Thu, 21 Aug 2003 05:51:59 -0700 (PDT) (envelope-from edelkind-freebsd-hackers@episec.com) Received: (qmail 9124 invoked by uid 1024); 21 Aug 2003 12:50:28 -0000 Date: Thu, 21 Aug 2003 08:50:28 -0400 From: ari To: freebsd-hackers@freebsd.org Message-ID: <20030821125028.GY55671@episec.com> Mail-Followup-To: ari , freebsd-hackers@freebsd.org, flowpriv@episec.com References: <20030817181315.GL55671@episec.com> <20030821065854.GA11586@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030821065854.GA11586@dan.emsphone.com> 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 12:52:00 -0000 dnelson@allantgroup.com said this stuff: > In the last episode (Aug 17), ari said: > > 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. > > Have you taken a look at Cerb? http://cerber.sourceforge.net/ > > It does something similar, but uses a C-like language to control a > processes actions. This lets you get extremely fine-grained control > (allow httpd to bind to only port 80, once), but the rules run as > "root", so they can grant as well as revoke privileges. A useful > modification would be to allow users to submit their own policies that > can only disallow actions (i.e. all arguments and process variables are > read-only, and the script can either pass the syscall through or return > a failure code, nothing else). I hadn't looked at cerb, though a C interface to systrace, or the modification of systrace to add a specialty function to the kernel, had passed though my mind. However, systrace is a good bit more complex than this should be, and the performance penalty can be significant. Neither programmers nor admins should be expected to implement something that slows down their programs on a wide scale, even if it would be advisable from a security standpoint. The implementation of flowpriv, however, will have a negligible performance impact (about three memory references per system call). I _do_ believe that systrace and flowpriv should work together, but i don't believe they should be consolidated. I have proof-of-concept code now, as a modification of 5.1-RELEASE-p2. I'll make a patch as soon as i get a chance; the idea may be a bit clearer then. ari