From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 21 10:01:28 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 6757516A4C3 for ; Thu, 21 Aug 2003 10:01:28 -0700 (PDT) Received: from webserver.get-linux.org (adsl-64-161-78-226.dsl.lsan03.pacbell.net [64.161.78.226]) by mx1.FreeBSD.org (Postfix) with SMTP id C873D43F3F for ; Thu, 21 Aug 2003 10:01:24 -0700 (PDT) (envelope-from oremanj@webserver.get-linux.org) Received: (qmail 11929 invoked by uid 1000); 21 Aug 2003 17:01:22 -0000 Date: Thu, 21 Aug 2003 10:01:22 -0700 From: Joshua Oreman To: Kris Kennaway Message-ID: <20030821170122.GC10811@webserver> References: <20030817181315.GL55671@episec.com> <20030821065854.GA11586@dan.emsphone.com> <20030821073900.GA90003@rot13.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030821073900.GA90003@rot13.obsecurity.org> User-Agent: Mutt/1.4.1i cc: hackers@freebsd.org 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 17:01:28 -0000 On Thu, Aug 21, 2003 at 12:39:00AM -0700 or thereabouts, Kris Kennaway wrote: > On Thu, Aug 21, 2003 at 01:58:54AM -0500, Dan Nelson wrote: > > > 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). > > Exercise for the reader: find a situation where the failure to perform > a syscall that normally succeeds, leads to privilege escalation :-) setuid(), seteuid(), setruid() -- Josh > > Kris