Date: Thu, 15 Apr 2004 08:43:12 -0400 From: "dodell@sitetronics.com" <dodell@sitetronics.com> To: eivind@freebsd.org, dodell@sitetronics.com, jilles@stack.nl, freebsd-arch@freebsd.org Subject: Re: [patch] lockf(3) user-exploitable kernel panic Message-ID: <99610-220044415124312827@M2W057.mail2web.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?99610-220044415124312827>