From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1LfjkF-00047e-4Y for garchives@archives.gentoo.org; Fri, 06 Mar 2009 23:46:23 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 74AE8E0087; Fri, 6 Mar 2009 23:46:21 +0000 (UTC) Received: from powerman.name (powerman.name [85.90.198.1]) by pigeon.gentoo.org (Postfix) with ESMTP id D3FBFE0087 for ; Fri, 6 Mar 2009 23:46:20 +0000 (UTC) Received: (qmail 10635 invoked by uid 1000); 6 Mar 2009 23:46:19 -0000 Date: Sat, 7 Mar 2009 01:46:19 +0200 From: Alex Efros To: gentoo-hardened@lists.gentoo.org Subject: Re: [gentoo-hardened] 2.6.27-hardened-r8: assassination Message-ID: <20090306234619.GC2278@home.power> Mail-Followup-To: gentoo-hardened@lists.gentoo.org References: <20090306215141.GA3005@home.power> <49B19FEB.13855.19525701@pageexec.freemail.hu> <20090306225746.GA2278@home.power> <1236381916.8071.25.camel@hangover> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-hardened@lists.gentoo.org Reply-to: gentoo-hardened@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1236381916.8071.25.camel@hangover> Organization: http://powerman.name/ User-Agent: Mutt/1.5.16 (2007-06-09) X-Archives-Salt: 51272da7-d3de-4093-9b28-04a0aacf0098 X-Archives-Hash: 7abae8cb10cf4c40a0491e854d39e266 Hi! On Fri, Mar 06, 2009 at 03:25:16PM -0800, Ned Ludd wrote: > FYI.. PaX Team maintains the PaX kernel and has little control over what > fixes go into the "next" hardened-sources. Also seems to me a little > strange that the PaX Team would have to put a work-around in the kernel > for a bug in glibc.. Seems like glibc should be fixed vs the kernel. Some changes in hardened-sources trigger this bug (which exists for years and don't bother anybody) and kill my servers (apache and perl are critical for normal server operation). I'm neither security expert nor Gentoo developer so I don't pretend to decide where/how this bug should be fixed and surely don't recommend to add any work-around in the kernel (but that at a glance looks like one of possible solutions because previous kernel don't trigger this bug). Only thing I need to know - how long I've to live with this workaround: is it will be fixed soon, or I have to prepare to redo these 'execstack -c' commands in next years after each math-pari/zend/ioncube upgrade... and be prepared to see other applications unexpectedly crash (on loading new plugin, for example) because of this bug. If we'll wait until "several years old glibc bug" will be fixed in glibc - it probably will take few more years. Anyway, thank you all for your work! And for providing this workaround, of course - it's much better to have one. -- WBR, Alex.