From owner-freebsd-arch@FreeBSD.ORG Thu Apr 15 05:43:14 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FFAD16A4CE; Thu, 15 Apr 2004 05:43:14 -0700 (PDT) Received: from relay3.mail2web.com (relay3.mail2web.com [168.144.1.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC41A43D55; Thu, 15 Apr 2004 05:43:13 -0700 (PDT) (envelope-from dodell@sitetronics.com) Received: from M2W057.mail2web.com ([168.144.251.165]) by relay3.mail2web.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 15 Apr 2004 08:43:12 -0400 Message-ID: <99610-220044415124312827@M2W057.mail2web.com> X-Priority: 3 X-Originating-IP: 81.69.92.101 X-URL: http://mail2web.com/ From: "dodell@sitetronics.com" To: eivind@freebsd.org, dodell@sitetronics.com, jilles@stack.nl, freebsd-arch@freebsd.org Date: Thu, 15 Apr 2004 08:43:12 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 15 Apr 2004 12:43:12.0732 (UTC) FILETIME=[36EA21C0:01C422E7] Subject: Re: [patch] lockf(3) user-exploitable kernel panic X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: dodell@sitetronics.com List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2004 12:43:14 -0000 Original Message: ----------------- From: Eivind Eklund eivind@FreeBSD=2Eorg Date: Thu, 15 Apr 2004 11:06:22 +0000 To: dodell@sitetronics=2Ecom, jilles@stack=2Enl, freebsd-arch@FreeBSD=2Eor= g Subject: Re: [patch] lockf(3) user-exploitable kernel panic On Wed, Apr 14, 2004 at 01:51:03PM +0200, Devon H=2E O'Dell wrote: >> Jilles Tjoelker wrote: >>>e) add a line 'struct proc;' to sys/ucred=2Eh >>=20 >> Thanks for this suggestion; I wasn't aware that this was reasonably=20 >> possible from an architectural standpoint=2E > >Most of the sys/* files are really owned by the implementation, and it >is usually OK to introduce forward declarations into them=2E We try to >avoid namespace poisoning (introducing unknown variables) for the >official files, but that also happens sometimes=2E > >Also, many of the files (including sys/ucred=2Eh) has an #ifdef _KERNEL >section=2E This section is totally owned by the implementation, and it i= s >(almost) always OK to add forward declarations=2E > >The list of official sys/ includes can be fetched at=20 >http://www=2Eopengroup=2Eorg/onlinepubs/007904975/basedefs/sys/ Thanks for the clarification here, Eivind=2E When implementing the=20 declaration in my current patch, I noticed that sys/ucred=2Eh had done this as well with struct thread=2E >> [snip] >> I'll look into implementing style(9) changes then=2E I know my patch fa= ils=20 >> a style(9) check in some contexts, so I'll go a general cleanup as well= =2E > >Please do that separately from the main patch=2E We try quite hard to no= t >mix stylistic and functional changes in a single patch, to make it easy >to use the version history (and easy for people to review the patches)=2E= I was aware of this policy=2E I'll make aesthetic changes to my current patch code and styleize the other code in a separate patch=2E >> sh has been fixed=2E I was under the impression that csh used libutil f= or=20 >> this (libutil has been fixed)=2E I'll take a deeper look into shells in= =20 >> base and in ports and figure out what changes I need to make there=2E=20= >> While I'm at it, I don't think it'd be a bad idea to go ahead and build= =20 >> in the RLIMIT_SBSIZE to bash and bash2=2E > >If it is easy, it might be worthwhile to patch the shells to use >libutil and submit those patches back to the maintainers=2E There are a huge number of shells to do this with=2E This subsystem looks like somewhat of a kludge to me in this respect; the functionality is plainly provided in libutil, while every shell (sh and tcsh included) have their own implementations=2E limits(1) even has statically compiled information about the limits for every shell it is aware of (including sh, csh, tcsh, bash/bash2 and a good few others)=2E I'll take a look at these later=2E=20 >> Ok=2E I was not aware that Linux had this fix / feature already=2E I'll= take=20 >> a look into the CVS repos of the other BSDs and see if it's something I= =20 >> can suggest a patch for in those worlds=2E > >It'd be nice to be compatible with Linux here, as it means just a define >is needed for making apps work with it on FreeBSD (it may even >automatically happen due to configure scripts=2E) My patch implements a per-user setting for this, since I thought that a malicious user might be able to spawn a large number of=20 processes, each eating up n locks=2E However, considering that POSIX locks are not inherited between processes and the=20 kern=2Emaxprocperuid sysctl, if it's desirable to be compatible with Linux in this case, I can certainly back out the per-user check and make it per-process=2E This would get rid of a good bit of code, including the setuid()-necessary changes=2E What would be a sane value for a per-process setting? Should I=20 calculate this value based on available system resources (as=20 kern=2Emaxfiles is set)? >Eivind=2E Thanks for the input! Kind regards, Devon H=2E O'Dell -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web=2Ecom/ =2E